[quote]Linux and Solaris users, and new in beta2, Windows users, who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property:
java -Dsun.java2d.opengl=true -jar Java2D.jar
[/quote]
Does this mean that if I take my 1.4.2 Java2D game, and run it under 5.0 with the above switch I will automatically get OpenGL acceleration for free(assuming I have OpenGL drivers installed) ? In particular does this mean translucent images will be accelerated?
So opaque rendering is over 100 times slower with opengl and transparent is 50% slower. Translucent is slightly better. The code is from Brackeen’s book and simply spits sprites at the screen and counts the images/sec.
Are these strange figures or am I missing something? The opengl switch seems to slow down more than it speeds up!
First of all hello ^^ i’ve been lurking over here for long but this si my first post .
Well it hapens the same to me, with the opengl pipeline disabled my little rendering experiment in java2d runs at 50 - 33 fps, with opengl enabled it does at 0 fps (one if lucky) both on Winxp with a geforce 5200 suposed to support opengl
There are a couple different issues contributing to the poor performance numbers you’re seeing… First, it appears that we’re having a problem (in our image management code) that makes us unable to cache the opaque.png, translucent.png, and antialiased.png images from David’s testcase in hardware. This means that we end up using software loops to copy the images to the screen, which explains why (in both the OGL and non-OGL cases) we’re slow in the non-translucent cases.
The problem appears to be isolated to the old Toolkit image loaders (which ImageIcon uses currently). If you modify his testcase to use ImageIO (or simply “new BufferedImage()”), you’ll see that the numbers are much more reasonable. In any case, I’ll have to investigate this further.
Regarding the comparitively poor performance of the opaque case with OGL enabled… As I mentioned, due to the bug described above, we always copy the sysmem-based copy of the image to the destination (since we don’t have a copy cached in VRAM). There is a performance bug in Nvidia’s OGL drivers for Windows that makes this case extremely slow, thus the low scores with OGL enabled. Nvidia fixed this in their most recent Linux drivers (6629), and the fix should also be included in their next Windows release as well.
So here again are the dangers of microbenchmarking. Low scores in one case can lead people to believe that the whole pipeline is slow or broken, but that isn’t the case. I’m still hoping to post an article that shows how the performance of the OGL pipeline compares to our existing pipelines. I’ll let you know when that’s up…
Also, we have some big changes to both our OGL and D3D pipelines coming soon to a Mustang build near you… So you should see those scores continue to improve in 6.0… We’ll make an announcement when those changes are available in the early Mustang builds.
So we have much better translucent performance with OpenGL/BufferedImage than with OpenGL/Image. However OpenGL/BufferedImage is still slower than non-OpenGL/BufferedImage for opaque and transparent images in this particular test.
I know I shouldn’t microbenchmark, but I just can’t resist!
