Do you think the performance of J2D with the pipeline enabled will ever be comparable (say within 10%) with that of an OGL binding?
Just wondered,
D.
Good question.
I’d say it’s already there in Mustang, but you know I’m a bit biased in this case. For a game that renders a couple thousand sprites onto the backbuffer each frame, there should be no discernable performance difference between Java 2D’s OGL pipeline and an OGL binding (LWJGL, JOGL). If your OGL app uses immediate mode rendering, then our OGL pipeline may actually be a slight win since we batch up our primitives to avoid unnecessary state changes and JNI overhead.
Anyway, why not write a simple app using both approaches and see what you get? That way at least we’ll have some hard numbers to chew on.
Thanks,
Chris
Immediate mode is hardly performant tho is it? Any decent application would either use display lists of VBO’s; how does j2D compare with those?
DP
What’s considerable is that with the OGL pipeline you get accelerated translucent images in Java 5. In Java 6 this acceleration is offered in the new D3D pipeline. Be aware that if you deploy a game via webstart than you can’t enable the OGL pipeline since setting the system flag would be ignored by webstart for security reasons. But you’re not limited to webstart as deployment options.
This was fixed in Mustang (JDK 6). You can now pass sun.java2d.opengl=true to a webstarted application.
Chris
Cool but this forces users to very likely download ans install Java 6, which bad because of the size of the JRE.
Any chance of backporting this flag to webstart Java 5?
That’s the point I was getting at, but I didn’t state it explicitly; I was comparing apples and apples, Java2D’s OGL pipeline to an app that uses OGL bindings in immediate mode. Immediate mode isn’t all bad, but of course if you use vertex arrays/buffers you have the potential to be faster than simply using immediate mode. But again, someone should hack up a testcase that compares all of these approaches (Java2D, LWJGL/JOGL w/ and w/o immediate mode) and then we will have some data.
Thanks,
Chris
There were enough issues with the OGL pipeline in JDK 5 (e.g. performance, robustness) that there probably wouldn’t be much benefit in having it backported. Still, if you want your voice heard you could post a comment on this bug report:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6250769
Chris
Well, I agree. I doubt that it’s worth voting for it.
Hi there,
Recently I did a speed comparisons of some very basic 2D drawing methods, basically I was just drawing lines on a canvas from a rendering loop and watching my frame rates. I have been comparing JRE1.5 plain Java2D , Mustang with OGL pipeline and JRE1.5+JOGL 1.1 implementations here are some of the results, sorry for being vague here as I don’t have time to dig up and rerun my benchmarks and post exact numbers and code.
JRE1.5 Java2D with default direct draw pipeline was ranging from 17 fps for 20000 lines up to 350 fps for 1000 lines JRE 1.5 with open gl pipeline was actually running slower than this it would give me 2 fps for 20000 lines
Mustang Java 2D (one of release candidates I grabbed from sun’s page) ranged from 15 fps with 200000 lines to 1500 fps with 1000
Java2d implementation used AWT canvas & buffer strategy as a rendering loop (I think this is what I have found around here as the most recomended rendering mechanism)
JRE1.5 JOGL 1.1 was drawing 2000000 lines with around 15 fps
I noticed that with pure JOGL I was able to increase number of lines while frame rate would only slightly go down while with Java2d the increas in number of lines would decrease my frame rate almost linearly.
Please note that I did these kinds of tests just for the purpose of picking the right API for very specific purpose, my rendering engine only ever paints 2d lines. So it would be interesting to see how the API’s would compare when they are doing doing bitmaped graphics as well. With JOGL it is possible to avoid the JNI overhead by using Buffers.
More detail would be great. Antialiased lines or jaggies & how long are they? How big is the screen (800x600?)?
I’m interested to know if I should invest in learning JOGL or just use the OGL pipeline like I am now.
My biggest gripe about J2D is that the y coordinate axis is backwards and flipping it ( AffineTransform.scale(1, -1) ) causes loss of graphics hardware acceleration.
On the other hand, the OGL pipeline is awesome because you can switch between OGL and the default renderer without any work. JOGL would make me stuck, and apparently so many cheap graphics cards are faulty/have faulty drivers when it comes to OGL.
Keith
Am I right in thinking there is only an OGL pipeline in JRE 1.5+ on Windows?
Anyway it sounds like the future for OGL accelerated J2D is rosy and as my game hardly ‘pushes the envelope’ I think I’ll stick with it for the moment!
D.
No, the OpenGL pipeline is also available at least for Solaris and Linux, don’t know about others.
However since IBM’s jre also supports this flag I guess its also supported on AIX if appropriate hardware would be / is available.
However keep in mind that it was ugly in 1.5 (very slow and unstable) and that still many drivers have problems with it.
I would at least offer a workarround for using the old pipeline if the OpenGL one does not work as expected.
lg Clemens