Re: Mac OS X 10.7+ / Oracle JRE 7 : Swing integration issues
Posted by Sven Gothel on Jan 10, 2013; 7:58pm
URL: https://forum.jogamp.org/Mac-OS-X-10-7-Oracle-JRE-7-Swing-integration-issues-tp4027780p4027786.html
On 01/10/2013 03:28 PM, InteractiveMesh [via jogamp] wrote:
> 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 <http://forum.jogamp.org/file/n4027780/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) ?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
URL: https://forum.jogamp.org/Mac-OS-X-10-7-Oracle-JRE-7-Swing-integration-issues-tp4027780p4027786.html
On 01/10/2013 03:28 PM, InteractiveMesh [via jogamp] wrote:
> 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 <http://forum.jogamp.org/file/n4027780/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) ?
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
signature.asc (909 bytes) | Free forum by Nabble | Edit this page |