GLCanvas draws over Swing components on Mac

On Mac OS X machines (no problems on Windows machines), the GLCanvas fills my entire Applet frame, drawing over all swing components such as a top menu bar and a side menu. During applet initialization, the swing components are briefly visible before the GLCanvas is drawn. Although not visible afterwards, the buttons in the top bar do still respond when I (blindly) click them. The GLJPanel behaves well in this setting (but renders less smoothly). The JOGL version is 2.0-RC8.

I'm a bit at loss in which direction to look for a solution. Any tip are very welcome :).

Ps. An old and possibly unrelated problem description: http://java.net/jira/browse/JOGL-58

EDIT: There are no alarming log messages.

Is it perhaps a combination of the heavyweight GLCanvas and the SWING layout manager BorderLayout? This problem described in "Heavyweight and Lightweight Issues", http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/jogl-1.1.0-windows-i586/Userguide.html, although a outdated.

I've tested setting the preferred, minimum and maximum dimensions of both the canvas component and its containing JPanel. Alas to no avail.

Hi

Actually, it is the same with any AWT heavyweight and Swing lightweight component under Mac OS X with Apple JVM, it is a known problem but not specific to JOGL. Maybe it is different with OpenJDK.

Thanks gouessej! Very helpful to start looking in the right places for a solution :).

To summarize, any combination of AWT and Swing is doomed to fail under Mac OS X with Apple JVM, even if the components do not overlap? I'm surprised to find so little solid information on such a considerable limitation.

Looking at solutions, the options appear to be:
> Use GLJPanel: This panel indeed fixed the mac problem for our product but does seem to impact the render performance.
> Use AWT only: We can replace the Swing components in our product with AWT solutions. Best performance but lacks the convenient Swing UI components.

A related post: http://forum.jogamp.org/Mac-OSX-GLJPanel-Performance-integrating-Swing-and-JOGL-td1002442.html

Any solid information or solution for this problem is very welcome.

Yes, there is a problem with Z ordering of components under Mac with Apple JVM, it's a shame. I worked on several commercial applications that have never been allowed to work on Mac because of such problems.

GLJPanel is heavier, of course it is still often slower and less reliable than GLCanvas and GLWindow, especially on low end graphics cards.

Are you sure you cannot try using OpenJDK to check if the mixing of heavyweight and lightweight components work fine with it? You can ship the JVM in commercial applications anyway (but it is not a common practice on Mac as far as I know).

I fear NewtCanvasAWT with Swing might have the same problem but you could give it a try.

Do you use JInternalFrame?

Thanks again for the very helpful ideas. New directions to add to our experiment list.

Regarding your question about the use of JInternalFrame. The first few levels of our UI are build up with nested JPanels using BorderLayout, with the root JPanel set as ContentPane of a JApplet. The GLCanvas is directly added into this nested JPanel UI.

The impact of the Z ordering problem on our Applet is a bit puzzling. Strictly speaking, the GLCanvas does not overlap our top menu bar in Z-ordering. The GLCanvas however does not respect the BorderLayout management and fills the entire JApplet ContentPane.  I guess the GLCanvas checks the available UI space on a different Z-level from where the rest of the UI is living and incorrectly concludes that the entire ContentPane is still free.

I'll definitely add the OpenJDK as a potential solution direction to our list. Perhaps in the same line of thought, the new Oracle JVM 7 for Mac might also be worth a shot?

An interesting discovery: GLCanvas does behave well in our desktop application, which starts in a JFrame instead of JApplet. The applet and desktop application share almost all their UI code.

It may seem that the problem is introduced by the java browser plugins.

Hi

Using Java Web Start in an heavyweight client (no applet) would work around your problem in this case.

Oracle JVM 7 for Mac is worth a try too but keep in mind that OpenJDK may contain much more interesting fixes.

AFAIK this is related to OSX's >= 10.5.8 offscreen rendering (CALayer).

We provide an OpenGL rendered layer to the CALayer, which will be composed
by the Cocoa / Plugin parent.

This artifact is even visible with the Version Info Applet, as shown here:
  <http://jogamp.org/deployment/jogamp-current/jogl-applet-version-napplet.html>

Either we lack providing essential clipping information or similar data
or the CALayer composer for the Applet is buggy.

AFAIK our offscreen window is of the correct size .. maybe somebody
likes to digg into this ?

Perhaps helpful, I've attached the jogl debug information for both the applet and the desktop application.

The applet size is 900 x 600. The GLCanvas size should be 900x955 (top 45 pixels is top bar) but is set to the full 900x600.
debug_log_mac_cleaned.txt

The desktop application correctly sets the canvas to 1030x701, leaving the rest of the GUI intact.debug_log_mac_desktop.txt

I've tested the applet with Mac OS X 10.7.4 and Oracle JRE 7u6 (instead of the default Applet jvm).
The log: debug_log_mac_oracle7_cleaned.txt

CLCanvas respects the Swing layout when ran with Oracle Java 7u6 Mac OS X Port (and doesn't when ran with Apple's most recent JVM).