Bug 642 - Exception when adjusting JSplitPane containing GLCanvas in RC11.
Summary: Exception when adjusting JSplitPane containing GLCanvas in RC11.
Alias: None
Product: Jogl
Classification: JogAmp
Component: awt (show other bugs)
Version: 2
Hardware: All windows
: --- critical
Assignee: Sven Gothel
Depends on:
Reported: 2012-11-21 09:25 CET by Mikael Christensen
Modified: 2012-12-22 06:07 CET (History)
1 user (show)

See Also:
Type: ---
SCM Refs:
jogl 1ae0737f34143a5ed655bd9c4d5fe9b0437c7774 jogl 4fa7bfd2018fe5a5c08157a26be22af194839718
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Christensen 2012-11-21 09:25:13 CET
In RC11 of JOGL, I get the following exception when adjusting a JSplitPane, containing a GLCanvas:

Unable to create temp OpenGL context for device context 0xe20124de

The problem is only encountered on Windows, and only on RC11 (RC10 worked). The problem disappears when changing to GLJPanel.

I've encountered the error on:
Geforce 310M - Win7 Pro 64-bit - Driver 306.23 - JOGL2.0-RC11
Geforce 310M - Win7 Pro 64-bit - Driver 306.97 - JOGL2.0-RC11
Geforce GTX570 - Win Vista 32-bit - Driver 296.70 - JOGL2.0-RC11
Geforce GTX570 - Win Vista 32-bit - Driver 306.97 - JOGL2.0-RC11

The code works on JOGL2.0-RC10 on all my test machines.

The code works on JOGL2.0-RC11 on macs. I've tested on Mac Mini (Geforce 9400M)
and Macbook Air (HD3000).

Full exception: 

Exception in thread "Timer-0" java.lang.RuntimeException: javax.media.opengl.GLException: Unable to create temp OpenGL context for device context 0xe20124de
	at jogamp.common.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58)
	at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:103)
	at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:205)
	at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172)
	at javax.media.opengl.Threading.invoke(Threading.java:191)
	at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:449)
	at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:74)
	at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:142)
	at com.jogamp.opengl.util.FPSAnimator$1.run(FPSAnimator.java:128)
	at java.util.TimerThread.mainLoop(Unknown Source)
	at java.util.TimerThread.run(Unknown Source)
Caused by: javax.media.opengl.GLException: Unable to create temp OpenGL context for device context 0xe20124de
	at jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:306)
	at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:572)
	at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:485)
	at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:645)
	at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:594)
	at javax.media.opengl.awt.GLCanvas$8.run(GLCanvas.java:996)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$400(Unknown Source)
	at java.awt.EventQueue$2.run(Unknown Source)
	at java.awt.EventQueue$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

Sample code reproducing the error (adjust the splitter to trigger a crash - resizing the window works):

public class JoglTest extends JFrame {	
	private static final long serialVersionUID = 1L;

	public static void main(String[] args) {
		SwingUtilities.invokeLater(new Runnable() {
		    public void run() {
		    	new JoglTest();
	public JoglTest() {
		Container contentPane = getContentPane();
		JSplitPane splitPane = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT);

		GLCanvas gc = new GLCanvas(new GLCapabilities(GLProfile.getDefault()));
		splitPane.setRightComponent(new JPanel());		
		contentPane.add(splitPane, BorderLayout.CENTER);

		FPSAnimator animator = new FPSAnimator(gc, 100);
		setSize(new java.awt.Dimension(824,568));
Comment 1 Julien Gouesse 2012-11-21 12:02:17 CET
It is not reproducible under GNU Linux (Mageia Linux 2, Nvidia Quadro NVS 285).

Please can you try to get the profile rather in a static initializer?
Comment 2 Mikael Christensen 2012-11-21 12:12:16 CET
I'm not sure exactly what you mean?

I tried creating a static GLProfile and passing it to the GLCanvas constructor, but it still crashes:

static GLProfile p;
static {
  p = GLProfile.getDefault();

Btw, the stack trace contains a WindowsWGLContext reference, so it seems to be Windows specific.
Comment 3 Mikael Christensen 2012-12-07 10:12:20 CET
Hi, anything new on this bug? Can I provide more information to help the process?
Comment 4 Sven Gothel 2012-12-07 16:03:46 CET
Probably related to bug 586, validating now ..
Comment 5 Mikael Christensen 2012-12-11 14:12:43 CET
As discussed in this thread: http://forum.jogamp.org/Swing-application-crashing-when-resizing-OpenGL-GLJPanel-window-td4027441.html, I found a workaround for this bug - if I put the GLCanvas inside a jawa.awt.Container and add this component to the JSplitPane, I no longer get crashes


Container viewerContainer = new Container();
viewerContainer.setLayout(new BorderLayout());
It seems the OpenGL context is no longer lost when resizing.
Comment 6 Sven Gothel 2012-12-22 05:43:13 CET
Fixed the root cause of the exception w/ commit 1ae0737f34143a5ed655bd9c4d5fe9b0437c7774.

However, yes - this workaround seems to be nice - especially for Windows,
where the mixed Lw/Hw JSplitPanel issue a remove/add when splitter is moved.
Note: This does not appear to happen on X11 ..
Comment 7 Sven Gothel 2012-12-22 06:07:05 CET
commit 4fa7bfd2018fe5a5c08157a26be22af194839718
demonstrates the Container use ..