Mac OSX GLJPanel Performance - integrating Swing and JOGL

We have a complicated desktop app that integrates JOGL and Swing in the same window. On Windows and Linux we do this by creating AWT Panels, placing them in front of the JOGL GLCanvas, and placing Swing components in the AWT Panel. This gives us all the benefits of hardware accelerated OpenGL without the cost or moving away from our Swing UI elements.

The current implementation of Swing and JOGL on the Mac does not allow us to use this same trick.

Our goal is to get maximum OpenGL performance without rewriting all the Swing based portions of our App.

At this point I see three reasonable paths forward and would like input from others in JOGL arena.

1) Debug why GLJPanel performance is so slow. Chatter on the forums suggests this is a known issue and I've not seen much discussion about how to get around it. Note that GLPbuffer performance is equally slow.

2) Use a GLCanvas but clip out rectangles using native OS API calls. We've done this in the past but it requires a bit of native code that we'd rather not maintain.

3) Draw the Swing controls into a bitmap and blit the bitmap onto a GLCanvas. This may create excess overhead when we have many many swing controls.

If you have ideas on this and which path is the best given the direction of JOGL, please let me know.

Bill

Take a look at this, if you havent already:
http://weblogs.java.net/blog/2005/03/11/str-crazy-improving-opengl-based-java-2d-pipeline

Get latest Java 6 JDK and pass in this system property -Dsun.java2d.opengl=true
(Haven't stress tested the performance yet)

There's also writing vertex and fragment shaders using GLSL so the graphics card does the brunt of the work.
(Just started experimenting with this)

Thanks, I read that and it looks like it's focused on JOGL performance overall. We're experiencing performance issues specific to MacOSX when using GLJPanel or GJPbuffer.

We are using the latest MacOSX (10.6.3), latest JRE (1.6.0_20-b02-279-10M3065), and the latest JOGL (downloaded via GIT on July 27, 2010). My Mac is using and NVIDIA GeForce 7300. The performance issues do not seem coupled to a particular type of drawn scene. Our JOGL experience goes like this:

MacOSX
    GLCanvas    fast
    GLJPanel    slow
    GLPbuffer   slow

Linux and Windows
    GLCanvas    fast
    GLJPanel    fast
    GLPbuffer   fast

We're trying to decide whether it's reasonable to fix the MacOSX slowness or if we should try to route around it.

Bill

Hello again, still looking for bit of guidance on GLJPanel here.

Here are our constraints.

- we have a large Swing based application which integrates OpenGL graphics and Swing JComponents.
- the graphics are typically behind all the JComponents but they can be arbitrarily nested using JPanels.

Based on the FAQ, we're already into the slowest corner for JOGL - I read this page:

http://jogamp.org/wiki/index.php/Jogl_FAQ#Why_using_Swing_for_high_performance_is_not_a_good_idea_.3F

So my question is whether anyone has done any specific performance analysis for GLJPanels on the Mac as the GLJPanel has acceptable performance on other platforms.

In case you're still watching, I did some performance analysis today.

The JGears demo spends about 89% of its time in the glReadPixels method on my mac.

Even when JGears is not drawing anything, the max frame rate is around 18 per second.

If we don't do the glReadPixels call, the frame rate goes up to about 600 per second.

My next step is to look at the native impl of glReadPixels is see if anything obviously fishy is going on there.

Bill

>In case you're still watching, I did some performance analysis today.

Yes I'm still watching :) Maybe it's also time to say stg :) Didn't dare to post stg coz I'm no Mac guy (Windoze) so I cant' really speak for JOGL on Mac. But at least I could give u some hints what the GLJPanel situation is on Windows XP/Vista/7 (at least to my personal experience) ...

First tl;dr version: GLJPanel is fucked up! Don't use it if u are not forced to use it. If u are forced to use it - work around it!

Secondly the long detailed version: The main problem with the GLJPanel is that it seems to used some kind of strange composition mechanism to do the Swing/OpenGL intermix. This (very) often (on most platforms I have tested) leads to lost hardware acceleration coz the driver is not capable to do the requested OpenGL rendering in hardware. Some drivers then simply ignore the command, some try to do the rendering stuff in some kind of fallback software implementation, wich is generally multiple orders of magnitude slower that the hardware rendering.

See here for a quite extensive discussion what can be done to improve the situation (vm switches, devblog hints etc.): http://jogamp.762907.n3.nabble.com/Texture-rendering-performance-problems-td966089.html#a966089

>The JGears demo spends about 89% of its time in the glReadPixels method on my mac.
>Even when JGears is not drawing anything, the max frame rate is around 18 per second.
>If we don't do the glReadPixels call, the frame rate goes up to about 600 per second.
>My next step is to look at the native impl of glReadPixels is see if anything obviously
>fishy is going on there.

If the GLJPanel is using glReadPixels its a strong indication of what I said above. The OpenGL output can not be intermixed with the Swing renderings by the hardware so software fallback/cpu rendering is used. So Java2D/Swing has to read the framebuffer back to client memory (cpu), compose it there and the upload it again to the gfxccard. This is ofcourse horribly slow and eats up all ur bus bandwidth.

I can't really suggest a solution here. On Windows it generally helps to switch of all fancy gfx stuff of the OS-GUI (Visual styles (DWM) on Vista/7) don't know if theres stg similar on Mac. Also it helps to play with the VM switches for Java2D for FBO/PBuffer/OpenGL usage.

Another quite radical solution is to use GLCavas and to render all ur Swing stuff using the TextureRenderer class. Thats quite straight foreward. The only tricky thing u need to take care of manually is to foreward the AWT-Events from the GLCanvas with some kind of proxy to ur custom rendered Swing components.

Hope that helps a little bit or at least points u in the right direction where to further investigate the issue ...

Thanks, I'll check out the byte order flags and we may fall back to drawing swing onto a glcanvas.  Initial tests with swing on a glcanvas were promising.

Bill

We have the same application structure.... ie lots of nested and sibling JPanels...

GLCanvas is good but then your rendering loop will be dependent on the AWT EDT.... was our previous solution. What worked for us is...

Newt with AWT Parenting check the junits for examples

http://github.com/sgothel/jogl/tree/master/src/junit/com/jogamp/test/junit/newt/parenting/

Here you will be more multithreaded...so performance gain...etc

Works great on Linux and Windows,

work is being done to stabilize the macosx version

Let me know if you need more info

I like the idea of improved performance but we have nested containment. JPanels on top of GLCanvas'es. On Linux and Windows, this works fine because the heavyweight windows do the clipping for us. On mac, not so much because the mac glcanvas can only be topmost in a given window.