Using -Dsun.java2d.opengl=true as startup argument for java when starting application using Java2D heavily (well, basically any Swing application), it improves noticeably performance in Linux environment.
Currently I’m experimenting following settings in my /etc/profile.local -file.
[code]
_JAVA_OPTIONS=’-Xverify:none -Dsun.java2d.opengl=true’
export _JAVA_OPTIONS
[/code]
(_JAVA_OPTIONS is magic environment variable which is used automatically by java).
I tested performance by running java -jar $JAVA_HOME/demo/jfc/Java2D/Java2Demo.jar with and without OpenGL pipeline enabled in my environment. I restricted my test into ”Images/WarpImage” -test.
Test setup:
– All options turned on (Anti-Aliasing, Rendering Quality, Texture, and Alpha Composite)
– Anim delay == 0ms
– Default window size
– ”Images/WarpImage” -test maximized to full window
I measure fps what I get with (and without OpenGL). Seemingly usage of ”Texture” was major slowdown in both cases.
Results: Without Texture
with OpenGL: 1000 fps
without OpenGL: 43 fps
Results: WithTexture
with OpenGL: 750 fps
without OpenGL: 23 fps
Based into this result OpenGL pipeline is around 20 times faster.
Secondary result what I got is that if there is two Swing applications concurrently using OpenGL pipeline, then huge performance drop occurs. For example, trying to run this same test concurrently in two windows. Just switch between Images and some other -tab in another Java2D demo window, and you will see huge performance variation in WarpImage test.
Regardless of that, it would be very interesting to always turn on this tuning option in Swing application running in Linux environment. However, here we have caveat emptor. If this optimization is turned on in Linux X11 environment where display doen’t have native support of OpenGL, then Mesa Open GL library is used instead. And if it’s used it is actually slower then normal ”non OpenGL” Java2D pipeline. Also this flag shouldn’t set for the M$windows since it has its’ own native DirectX accelerator used by default.
This makes issue rather interesting when trying to utilize full speed in Webstart deployed application. Perhaps best alternative is to define flag always, and if necesasary provide two separate JNLP -startup files in webserver to resolve potential problems.
References: