Posted by Demoscene Passivist on Aug 02, 2010; 9:43pm
URL: https://forum.jogamp.org/Mac-OSX-GLJPanel-Performance-integrating-Swing-and-JOGL-tp1002442p1017347.html

>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 ...