Bug 1004 - GLCanvas displays an empty rectangle in Applets on Mac OS X
Summary: GLCanvas displays an empty rectangle in Applets on Mac OS X
Status: VERIFIED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: applet (show other bugs)
Version: 2
Hardware: All macosx
: --- normal
Assignee: Sven Gothel
URL:
Depends on: 983
Blocks:
  Show dependency tree / graph
 
Reported: 2014-04-18 19:09 CEST by David Collins
Modified: 2014-05-23 19:36 CEST (History)
2 users (show)

See Also:
Type: DEFECT
SCM Refs:
gluegen f39100b35d0833764f2220e487ea7ea05ed87352 jogl aa1c04ebee23d0803880d6d68ae73109c1a5c178
Workaround: TRUE

Attachments
Java console output from JOGL Gears Applet (30.72 KB, text/plain)
2014-04-18 19:09 CEST, David Collins 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Collins 2014-04-18 19:09:20 CEST 
Created attachment 613 [details]
Java console output from JOGL Gears Applet

Overview
Java Applets containing a GLCanvas run on Mac OS X without crashing, but GLCanvas displays an empty rectangle. This issue has been reproduced on Mac OS X 10.9.2 with JOGL 2.1.5, using Java plugin versions 1.7.0_55 and 1.8.0_05. Additionally, this issue has been reproduced on the following graphics cards: ATI Radeon HD 5750; NVIDIA GeForce 9600M GT.

Steps to Reproduce
1. Visit the following page from a machine running Mac OS X 10.9.2 and Java 1.7.0_55 or 1.8.0_05:
https://jogamp.org/deployment/jogamp-current/jogl-demos/applet-gears.html
2. View the Java console output. The attached document Gears.txt shows the log output on a Mac OS X machine that reproduced this issue.

Actual Results
GLCanvas displays an empty rectangle.

Expected Results
GLCanvas displays the contents of the OpenGL scene. In the above Steps to Reproduce, GLCanvas should display the contents of the JOGL Gears demo scene.

Build Date & Platform
2.1.5 on Mac OS X 10.9.2 with Java 1.8.0_05

Additional Builds and Platform
2.1.5 on Mac OS X 10.9.2 with Java 1.7.0_55
Comment 1 Sven Gothel 2014-05-07 21:35:09 CEST 
+++
java.lang.NullPointerException
	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1003)
	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:998)
	at sun.awt.SunToolkit.getSystemEventQueueImpl(SunToolkit.java:993)
	at java.awt.Toolkit.getEventQueue(Toolkit.java:1749)
	at java.awt.Component.repaint(Component.java:3405)
	at java.awt.Component.repaint(Component.java:3305)
	at com.jogamp.nativewindow.awt.JAWTWindow.attachSurfaceLayer(JAWTWindow.java:335)
	at jogamp.opengl.macosx.cgl.MacOSXCGLContext$NSOpenGLImpl$AttachGLLayerCmd.run(MacOSXCGLContext.java:726)
	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:95)
+++

Similar, if not equal, to Java3D Bug 983

Maybe we can copy the _workaround_ applied to Java3D, 
Bug 983 Comment 9, to JOGL's JAWTWindow ?

+++

Also see forum thread:
  <http://forum.jogamp.org/Jogl-2-stops-working-on-Mac-after-Java7-update-55-tp4032286.html>

+++
Comment 2 Sven Gothel 2014-05-07 21:38:13 CEST 
(In reply to comment #1)
> +++
> java.lang.NullPointerException
> 	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:1003)
> 	at sun.awt.SunToolkit.getSystemEventQueueImplPP(SunToolkit.java:998)
> 	at sun.awt.SunToolkit.getSystemEventQueueImpl(SunToolkit.java:993)
> 	at java.awt.Toolkit.getEventQueue(Toolkit.java:1749)
> 	at java.awt.Component.repaint(Component.java:3405)
> 	at java.awt.Component.repaint(Component.java:3305)
> 	at
> com.jogamp.nativewindow.awt.JAWTWindow.attachSurfaceLayer(JAWTWindow.java:
> 335)
> 	at
> jogamp.opengl.macosx.cgl.MacOSXCGLContext$NSOpenGLImpl$AttachGLLayerCmd.
> run(MacOSXCGLContext.java:726)
> 	at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:95)
> +++
> 
> Similar, if not equal, to Java3D Bug 983
> 
> Maybe we can copy the _workaround_ applied to Java3D, 
> Bug 983 Comment 9, to JOGL's JAWTWindow ?
> 
> +++
> 
> Also see forum thread:
>  
> <http://forum.jogamp.org/Jogl-2-stops-working-on-Mac-after-Java7-update-55-
> tp4032286.html>
> 
> +++

Further references:

  <http://stackoverflow.com/questions/17223304/appcontext-is-null-from-rmi-thread-with-java-7-update-25>

  <http://stackoverflow.com/questions/17275259/nullpointerexception-in-invokelater-while-running-through-java-webstart/20102779#20102779>
Comment 3 Sven Gothel 2014-05-11 03:55:36 CEST 
(In reply to comment #2)
> Further references:
> 
>  
> <http://stackoverflow.com/questions/17223304/appcontext-is-null-from-rmi-
> thread-with-java-7-update-25>
> 
>  
> <http://stackoverflow.com/questions/17275259/nullpointerexception-in-
> invokelater-while-running-through-java-webstart/20102779#20102779>

Oracle's bug reports:
  <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8019274>
  <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8019272>

Note:
  "SQE-OK to defer this issue to 7u60/8u20"
Comment 4 Sven Gothel 2014-05-12 01:09:40 CEST 
JAWTWindow: Non intrusive workaround for Bug 1004 and providing AppContextInfo to mitigate related bugs, e.g. Bug 983

Bug 1004, as well as Bug 983, are caused by issueing certain AWT tasks
from a Thread which ThreadGroup is not mapped to a valid sun.awt.AppContext (AppContext).

The 'certain AWT tasks' are all quering the current EventQueue instance,
which is associated to the AppContext.
This operation will fail and cause a NullPointerException.

This workaround simply gathers a ThreadGroup
which is mapped to the desired AppContext.

This AppContext ThreadGroup is being used to launch a new Thread
which is then mapped to an AppContext and hence can issue
all AWT commands.

+++

In the Bug 1004 scenario, JAWTWindow is constructed
from within the AWT EDT, which ThreadGroup does belong to the AppContext.

Here the issue is that an AWT operation was invoked from the OSX main thread,
which itself does not belong to the AppContext.
The workaround as described above solves this issue.

+++

For Bug 983 the scenario is different, since JAWTWindow is _not_
constructed from a thread which ThreadGroup is mapped to the AppContext.
[It is also not constructed on the AWT-EDT].

It is recommended to have Java3D gathering the AppContextInfo itself early
and issues the JAWTWindow creation on an eligible thread using
AppContextInfo.invokeOnAppContextThread(..)
similar to JAWTWindow.attachSurfaceLayer(..).

This will allow removing the more intrusive remedy
of Java3D commit bdda2ac20bfef85271da764d1989ec3434d5c67a
and simply issuing the crucial commands on a proper thread.

+++

The more intrusive workaround of above commit
does not work in general at least for Bug 1004 (OSX and Applets).
While forcing the mapping of the 'alien' thread-group
to the AppContext work for the 1st launch w/ the 1st AppContext,
a second launch w/ a new AppContext will fail.

Here we did update the new AppContext knowledge in AppContextInfo,
however a NPE is received in getEventQueue() .. since the AppContext
is gathered after patching, but the EventQueue is still null.

Further more, using static knowledge of AppContext/ThreadGroup mapping
violates at least the Applet lifecycle. Here we can have one ClassLoader
with multiple AppContext - i.e. Applets.
Comment 5 Sven Gothel 2014-05-12 01:11:46 CEST 
gluegen f39100b35d0833764f2220e487ea7ea05ed87352
jogl aa1c04ebee23d0803880d6d68ae73109c1a5c178
Comment 7 Sven Gothel 2014-05-21 09:07:52 CEST 
@David: Can you please confirm, i.e. verify ? Thank you!

Others may verify this issue as well, thank you.
Comment 8 David Collins 2014-05-23 19:36:49 CEST 
Verified this fix in Java 1.7.0_55 and Java 1.8.0_05.

@Sven: Thank you very much for looking into this and resolving it. We'll look forward to the next JOGL release containing these changes.