the JOGL pre-experience
JOGL vs. Java2D
This blog entry is all about performance testing JOGL against Java2D.
Those who have tried to push 1k+ lines (don’t ask me why this is a good idea … it just happens sometimes) or a similar number of shapes through Java2D in real time might have faced the “spiral of dispair” that goes something like:
- Profile & ensure repaint regions are minimal
- Tweak the JVM settings, ala this guide or insider forum posts (e.g. Chris Campbell or the Swing Labs)
- Scale back what you’re trying to do (nooo!)
Enter JOGL, a port of OpenGL to Java! The Java2D pipeline has a number of inherent performance problems due to its (relative to OpenGL) high level of abstraction non-integration of low-level details into its abstraction.
- Shapes are stored pre-tesselated, forcing tesselation to occur on each render. GeneralPath could have a #tesselate function, which would give a more primitive path
- Stroking allows for arbitrarily complex geometric transformations, but simple transformations like a dotted line could be accomplished more efficiently with a bitmask, ala stippling
- The call depth in Java2D is out of control. I believe just the overhead of calling drawLine(int, int, int, int) 1k+ times is significant.
OpenGL, although a low-level state machine experience, was designed to overcome these problems. Below are the results of performance tests I’ve run with JOGL and Java2D. I’ll keep them coming as I continue to use JOGL, of which I am now a believer. Btw, did you know that Processing is built on top of JOGL?
svn: http://resisttheb.org/rtb/graphics_perf