From my reading it seems as though Java 2D graphics are in a mess at the moment. There’s:
Java2D,
Java2D with the OGL pipeline
JOGL/LWJGL
Some programmers could have reservations about JOGL for these reasons:
As far I have found JOGL and the J2D ogl pipleline are not integrated at all.
Sun are improving J2D with things like Chris Campbell’s STR-enhancement which comes out in Mustang. This enhancement apparently makes for faster J2D since it minimise JNI method calls by batching them together (only done for the J2D ogl-pipeline, but could also be done for windows X11 rendering mode too) .
It is said that on Windows X11 is a better fit and OGL will never be enabled for Java2D by default. Is X11 faster than OGL on windows?
Right now JOGL is the way to go because J2D is not reliably hardware-accelerated, even in ogl-pipeline mode, but in the future J2D will imporve… so are these concerns fair?
WIll STR and other enhancements for J2D be possible for JOGL?
I cannot speak for much of your concerns, but I know there is an example you can download alongside the Mustang preview release wherein JOGL and Java2D are both used on top of each other in one situation or another, so that may cover that first concern of yours in the future.
Hopefully, someone will be around to properly answer the rest and maybe elaborate on mine.
OpenGL is MUCH easier to learn than Java2D and it allows for better access to hardware for things like shaders which can be used to create special effects for 2D.
Java2D you need to learn how to accelerate your images(I forget thow to do this often), how to keep a balance of performance vs design and you need to learn how not to slow down your program which is easy to do if you aren’t careful.
In Mustang there is now support for Java2D and JOGL interoperability. This allows full hardware acceleration for 3D graphics and full interoperability with Swing widgets. We’re just beginning to scratch the surface of the effects possible with this integration.
You mean DirectDraw, not X11. Yes, the STR improvements are great for performance and robustness and also help enable the Java2D/JOGL bridge.
Again, DirectDraw, not X11. OpenGL is just as fast as DirectDraw on Windows if vendors provide good OpenGL drivers for their cards. NVidia’s are typically the most robust and lead the way in implementing new features; ATI’s are usually pretty fast but not as robust. I could forsee the Java2D/OpenGL pipeline being enabled by default at least on certain vendors’ cards at some point.
J2D is pretty reliably hardware accelerated already. J2D and JOGL solve different problems. J2D is a very well specified and portable 2D rendering library with high-level primitives to make drawing easy. JOGL exposes raw OpenGL to the programmer which enables many more effects but has a steeper learning curve.
STR in Java2D’s sense doesn’t apply to JOGL; we do no batching or other interposition on OpenGL calls by default (the DebugGL and TraceGL pipelines are exceptions). However we do by default perform all OpenGL work in JOGL on one dedicated thread to work around OpenGL driver problems seen on basically all OSs.
[quote]J2D is a very well specified and portable 2D rendering library with high-level primitives to make drawing easy. JOGL exposes raw OpenGL to the programmer which enables many more effects but has a steeper learning curve.
[/quote]
I detest that.
OpenGL is easier to use and has less of a learning curve than J2D assuming you understand the math behind it and how it works.
I find setting up a simple project to be faster and headache free under JOGL than Java2D.
The question doesn’t make sense. What is “pure OpenGL” ? OpenGL is an API for graphics. JOGL is just a way to access that API from Java. It is not “impure”. I think what you meant to ask is “What are the performance differences that result from calling OpenGL from Java vs. calling OpenGL from C, C++, assembler, Pascal, etc… ?”
I.e. a language that (ahead-of-time) compiles to processor specific, OS specific code, vs. a laguage with a layer of abstraction like the JNI.
The answer appears to be that the difference is not significant enough to worry about.
