Mac OS X 10.7+ / Oracle JRE 7 : Swing integration issues

While running JOGL in Swing applications on OS X 10.7+ / JRE 7 some issues arise when the JREs 7u10 and 7u12-ea-b08 (2013/01/03, http://jdk7.java.net/download.html) are used.

The next release 7u12 includes a bug fix concerning the positioning of a heavyweight AWT Canvas.

The following test cases render the Gears demo with 4xMSAA into a GLCanvas or NewtCanvasAWT which are added to Swing containers/layouts like JPanel/BorderLayout, JLayeredPane, JSplitPane, and JTabbedPane.

javax.media.opengl.awt.GLCanvas
 - GearsGLCanvas (sole child, BorderLayout.CENTER)
 - GearsBorderLayout
 - GearsJLayeredPane
 - GearsJSplitPane
 - GearsJTabbedPane
   
com.jogamp.newt.awt.NewtCanvasAWT
 - GearsNewtCanvasAWT (sole child, BorderLayout.CENTER)
 - GearsNewtBorderLayout
 - GearsNewtJLayeredPane
 - GearsNewtJSplitPane
 - GearsNewtJTabbedPane

archive : GearsLayoutTests.jar
main classes : jogl.test.gears.<sample name>
GearsLayoutTests.zip

Issues

1. GLCanvas and NewtCanvasAWT are rendered always in the front (7u10 and 7u12-ea-b08).

The canvases are always in front of all layers within the JLayeredPane, althought they should be rendered bottommost.
 
The canvases are always in front of the JTabbedPane no matter which tab is selected.

2. GLCanvas and NewtCanvasAWT are positioned at the lower left corner at start time (only 7u12-ea-b08).

Both canvases are not positioned correctly within their parent container when the JFrame gets visible. Their lower left corner is at the lower left corner of the JFrame. As soon as the canvases are resized they move to the correct position, except for JLayeredPane.

On 7u10 the canvases are always rendered at the right place, except for JLayeredPane.

Questions

1. Does JOGL compensate the positioning bug itself (JDK 7 Bug 2229714 : [macosx] JAWT native CALayer not positioned over Canvas http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2229714) ?

2. Does this result in wrong positioning in 7u12 or is 7u12 buggy ?

3. How to detect if the wrong rendering is caused by the JRE or by JOGL ?

Wrapping the canvases with a heavyweight Panel has no effect. The colored background area of the canvases are always painted at the right place with the right size. Mouse input is received exactly in this area. All samples run fine on Windows.

August

On 01/10/2013 03:28 PM, InteractiveMesh [via jogamp] wrote: We sort of force the relative x/y position of our CALayer to be 0/0,
i.e. opaque at the AWT position.

>
> 2. Does this result in wrong positioning in 7u12 or is 7u12 buggy ?

You referred to the z-position. The x/y position is unrelated.
The z-position is related to heavy/lightweight rendering AFAIK,
i.e. our GLCanvas or NewtCanvasAWT is heavyweight and opaque,
where the lightweight stuff is offscreen and composited later on
following the z-position. (z-pos.. == z-stacking ..).

In short, Swing lightweight and heavyweight mixing mileage always vary a lot.
If in doubt, you maybe forced to use GLJPanel.

>
> 3. How to detect if the wrong rendering is caused by the JRE or by JOGL ?
>
> Wrapping the canvases with a heavyweight Panel has no effect. The colored
> background area of the canvases are always painted at the right place with the
> right size. Mouse input is received exactly in this area. All samples run fine
> on Windows.

Problem is the different lw/hw related implementation on the specific OS.
I.e. OSX uses the CALayer etc for _all_ types of things nowadays,
hence their compositioning is different.

In short: Hw/Lw mixing w/ z-position involved is unstable!

~Sven

>
> August

Hi Sven,

This is the same as my problem: http://forum.jogamp.org/Mac-OS-X-10-8-Java-7-Poor-Animation-and-Lockups-tt4027723.html

This also appeared with Oracle JRE 7 and OS X 10.7.  

I know z-ordering is complicated, but setVisible(false) as used in JTabbedPane and CardLayout ought to be doable.  No?

We are shipping this year's Mac edition of our app with JOGL features disabled due to this problem.

Thanks,
Gene

On 01/13/2013 06:19 AM, Gene [via jogamp] wrote:
> Hi Sven,
>
> This is the same as my problem:
> http://forum.jogamp.org/Mac-OS-X-10-8-Java-7-Poor-Animation-and-Lockups-tt4027723.html
>
Bug 664 - yes, it's reproducible.
Sadly I was busy with Exclusive Context Thread (ECT) feature,
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=224fab1b2c71464826594740022fdcbe278867dc>

But we cont. walking through the bug list.

> This also appeared with Oracle JRE 7 and OS X 10.7.  
>
> I know z-ordering is complicated, but setVisible(false) as used in JTabbedPane
> and CardLayout ought to be doable.  No?

See above & maybe.

>
> We are shipping this year's Mac edition of our app with JOGL features disabled
> due to this problem.

Well, sorry for that. If you only offer one release per year, nothing we can do about it.

Best and stable experience is w/ using NEWT
and NewtCanvasAWT (to attach it to an AWT component).

In case you
need Swing z-stacking / compositioning, pls use GLJPanel.
GLJPanel should work out of the box w/ Swing anyways, even though it's
performance is not best due to the FBO offscreen -> Image copy.

Heavyweight AWT GLCanvas usually works fine, in a heavyweight AWT tree .., well.

Last but not least, one could query the platform via
using com.jogamp.common.os.Platform and check OS_TYPE etc,
if carefully validated that a feature does work one way on certain systems.

Of course, I don't like this approach either but hope w/ diligent bug walking
those hiccups will be solved soon. Of course, this also requires Java7 on OSX
to become more stable as well.
On the latter platform, we still see freezes and JVM crashes every now and then
and I would only mark it 'experimental' and not 'production ready'.

~Sven

>
> Thanks,
> Gene

Thanks.  This year was tough because Apple cut off support for Java 6 and Oracle Java 7 is all that will run on Mountain Lion.  We could not afford to support two Apple versions (JRE6 + JRE7), and Oracle tools do not let you package a JRE 6 in an app bundle.  It's a perfect storm of incompatibility.

We do bug-fix releases between annual majors, but since our software drives an annual contest most of the downloads occur in January.  If we can fix it later in the year, it's a good thing, but most schools (primary users) won't go through the trouble to re-install.

Thanks again for all your work.

maven pushed on jogamp '2.0.2-rc20130404'
based on '2.0.2-rc-20130404',  'http://jogamp.org/deployment/archive/master/gluegen_656-joal_420-jogl_951-jocl_773/'

OSX CALayer / Java7 issues should be fixed w/ this version 'once and for all'

Hi
I'm using the April the 4th version from Maven, but still seeing the NoClassDefFoundError: apple/awt/CGraphicsDevice error when making a JCanvas3D- is there anything else I need to do other than use the latest Jogl from Maven?

Sorry, my mistake - this was a Java3D issue and was caused by the old Java3D jars being installed as system-wide extensions in OSX Mountain Lion. They were installed in the "System" folder rather than the library folder, and this is a pretty new laptop so I suspect that they are installed as a standard part of the Java1.6 install that comes with the OS.

Running my test cases (see initial post of this thread) with

 - gluegen-2.0-b671-20130517
 - jogl-2.0-b993-20130518

leads to following results:

on 7u21
 - GLCanvas and NewtCanvasAWT are positioned correctly (x/y-position). :-)
 - GLCanvas and NewtCanvasAWT are rendered always in the front (z-position). :-(

on 7u40-ea-b27, 2013/05/30 and 8ea-b92, 2013/05/30
 - GLCanvas and NewtCanvasAWT are positioned permanently at the lower left corner (x/y-position). :-(
 - GLCanvas and NewtCanvasAWT are rendered always in the front (z-position). :-(

So, I assume that the current jogl build isn't yet adapted according to the x/y-position bug fixes (JDK 7 bug 2229714/JDK 8 bug 7172187 : JAWT native CALayer not positioned over Canvas) which are implemented in 7u40-ea-b27 and 8ea-b92.

In my view the z-position issue in not caused by jogl and can only be solved within the Swing layouts.

August

InteractiveMesh wrote

Running my test cases (see initial post of this thread) with

 - gluegen-2.0-b671-20130517
 - jogl-2.0-b993-20130518

leads to following results:

on 7u21
 - GLCanvas and NewtCanvasAWT are positioned correctly (x/y-position). :-)
 - GLCanvas and NewtCanvasAWT are rendered always in the front (z-position). :-(

on 7u40-ea-b27, 2013/05/30 and 8ea-b92, 2013/05/30
 - GLCanvas and NewtCanvasAWT are positioned permanently at the lower left corner (x/y-position). :-(
 - GLCanvas and NewtCanvasAWT are rendered always in the front (z-position). :-(

So, I assume that the current jogl build isn't yet adapted according to the x/y-position bug fixes (JDK 7 bug 2229714/JDK 8 bug 7172187 : JAWT native CALayer not positioned over Canvas) which are implemented in 7u40-ea-b27 and 8ea-b92.

In my view the z-position issue in not caused by jogl and can only be solved within the Swing layouts.

August

Sorry for the long reply, this thread unfortunately got buried inside the forum.
I brought up the question again on the JogAmp IRC channel
http://jogamp.org/log/irc/jogamp_20130625100341.html#l17

Please create a bug-report, inside the jogamp bugzilla, with this information and preferably with a test exposing the issue using 7u40 or 8ea-b92 it will help to reevaluate and check for a potential regression.
Do we know which change to JDK 7/8 OpenJDK codebase introduced this  left corner (x/y-position) issue while using 7u40-ea-b27, 2013/05/30 or 8ea-b92, 2013/05/30 ?

There is a new EA build 7u40 Build b29, will this build improve the situation?
https://jdk7.java.net/download.html

Cheers
Xerxes

Hi all,

I am facing the same issue.

I verified the latest releases from oracle jdk u40b38, unfortunately the problem is still there.

In my case, I have no choice but to use the GLCanvas on Mac as it provides a much needed performance improvement over GLJPanel.

I was wondering, Is there a way to override or hack the GLCanvas to not be affected by the jdk fix:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2229714

P.S: I am using JOGL and GlueGen release 2.0.2 ...

Is there a most recent release from JOGL that handles the issue?

Best,

Bassel

On 08/15/2013 06:17 PM, bmorcos [via jogamp] wrote: Not yet .. but it's on the prio list .. even though we have no bug report
for this .. yet. Maybe you can do the bug report?

Estimated time for fix .. ~1 week.

~Sven

Sven,

Great to hear that it's in the pipeline.

I created Bug 816:

https://jogamp.org/bugzilla/show_bug.cgi?id=816

It's my first entry, so am not sure I filled everything required.

How will this work? would there be a new jogl release that I can grab from git repo when the bug is fixed?

Also, if you don't mind me asking, do you have an idea about when this "minor release" would happen?

thanks again!

Bassel