I think that java2D gets really fill rate limited when using the d3d pipeline on integrated chips.

For example: my laptop has optimus and never seems to use its dedicated gpu. When I run my particle editor, it can render 1k+ particles fine as long as they are small sizes 1-5 pixels. The moment you try rendering an image above 300 it drops to a screeching halt. When using the opengl flag, it performs how it should and does not seem to be fill rate limited. I do not know what java uses on macs but I think there might also be an issue there.

If others out there could test this maybe that would be sweet. By test I mean try rendering multiple images with and without the opengl global flag set and see if there is a difference in performance.

Java2D is ok to use, that flag obviously not: on my computer it results in empty black windows when enabled, no matter which Java application.So be careful when shipping anything with the flag enabled.

So i played with your test code a bit and was very surprised. Most of what you did was the fastest way of doing things and there was nothing to complain about but the interesting thing i found out was how fillrate limited java2D really is.

For example: 256*256 30fps 2k sprites. Drop it to 128*128 200+ fps. Also, scaling instead of before hand but when the balls were called to render, did not change the performance. Everyone says scaling like that is big fps drop. I see no difference what so ever.

Make things fast and not slower? Is it because the lower the transparency the less pixels have to be drawn? The lower I make it the faster things run. At .1 I get 2k 256*256 at 90 fps. I am really lost now as I thought alpha was a killer in performance.

I have a fully GPU accelerated particle engine which renders particles as transparent untextured square points. The particles bounce on the screen edges (it's in 2D), but they are treated as 1 pixel points, meaning that they'll only bounce when half the particle is already outside the screen. This "increases" fillrate since that part is clipped, and is especially noticeable with larger particles. That combined with the increased number of vertices to process reduces performance as the particles become smaller.

If the above (256x256) result is with Java2D I'll be surprised. Either:1. a big number of the particles are outside the screen and get clipped,2. you have a pretty powerful graphics card and Java2D has perfect OpenGL acceleration

It's definitely not impossible though. With only 1600 particles the CPU cost of even glBegin/glEnd might be low enough to allow 60 FPS, so Java2D might be able to handle it even if it's not very CPU effective. The hardware can handle it, just look at a GTX 680:

32.2 Gpixel/s... *drool*

@StumpyStrustScaling images (textures) is hardware accelerated. Up-scaling it even with bilinear filtering should be free and faster than upscaling it and storing it in memory, since your GPU needs to read less texture memory. Transparency is also often free on newer GPUs since the blending is also handled by dedicated hardware. I have no idea why it gets faster with lower transparency. Your GPU should do the exact same work no matter what alpha value you have.

Scaling images (textures) is hardware accelerated. Up-scaling it even with bilinear filtering should be free and faster than upscaling it and storing it in memory, since your GPU needs to read less texture memory. Transparency is also often free on newer GPUs since the blending is also handled by dedicated hardware. I have no idea why it gets faster with lower transparency. Your GPU should do the exact same work no matter what alpha value you have.

The more transparent you make the draw, the more pixels will be completely transparent at the edges, and they are therefore not processed at all. Seems to imply software rendering though.

Cas

Wait, does SRC_OVER simply subtract (or add) that amount of alpha from/to each pixel? If so, it does imply software rendering like Cas said, since invisible and fully opaque pixels don't require any blending.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org