---- Reported by mithrandir 2003-11-25 16:21:37 ---- When creating a managed render thread, using setRenderingThread()/setNoAutoRedrawMode() if the window is not visible initially, then GLEventListener callbacks are not called. For example: class Myframe extends Frame implements Runnable { MyFrame() { GLDrawableFactory fac = GLDrawableFactory.getFactory(); canvas = fac.createGLCanvas(caps); canvas.addGLEventListener(this); add(canvas); // setVisible(true) here will have callbacks work correctly Thread th = new Thread(this); th.start(); setVisible(true); } public void run() { canvas.setRenderingThread(Thread.currentThread()); canvas.setNoAutoRedrawMode(true); while(some_condition) canvas.display(); } } In this code, the following exception is generated (includes a few lines of our internal test program): net.java.games.jogl.GLException: Surface already unlocked at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.unlockSurfa ce(WindowsOnscreenGLContext.java:192) at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.free(Window sOnscreenGLContext.java:134) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:203) at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:182) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:82) at org.j3d.aviatrix3d.surface.SimpleAWTSurface.run(SimpleAWTSurface.java :349) at java.lang.Thread.run(Thread.java:534) After this point, no further events are generated to the listeners. By uncommenting the first setVisible() call and commenting out the later, repainting and event generation occurs as expected. ---- Additional Comments From kbr 2005-01-26 13:06:34 ---- This problem is still reproducible with the latest JOGL (1.1 b07). It appears to be due to a race condition in the GLContext implementation. Running it under the debugger succeeds. I'll attach a complete test case. ---- Additional Comments From kbr 2005-01-26 13:08:21 ---- Created an attachment Complete test case ---- Additional Comments From kbr 2005-01-27 18:57:21 ---- The issue (or a related one) is still present in the current JOGL build, although the symptom was different: a deadlock upon startup of the application. When the OpenGL context is created in the WindowsOnscreenGLContext implementation, it causes Component.getGraphicsConfiguration() to be called, which causes the AWT tree lock to be grabbed. Under some circumstances, another thread can already hold the AWT tree lock and call GLContext.invokeGL(), which leads to a classic deadlock. Resolved this by eagerly grabbing the tree lock under some circumstances (not all the time) before entering the synchronized invokeGL in (only) the Windows onscreen context implementation. Note that the first test case attached above hangs or crashes the JVM upon exit, apparently because the OpenGL context is active while the process is being taken down. This has been seen in other applications as well. To the best of my knowledge it is not due to a lack of synchronization in JOGL, but probably due to a driver bug when the process is torn down while asynchronous OpenGL rendering is being performed. To work around this problem a modification to the application is required to cooperatively shut down the animation thrad, as is done in JOGL's Animator class and in the JOGL demos. A revised copy of the test case which works has been posted above. ---- Additional Comments From kbr 2005-01-27 18:58:06 ---- Created an attachment Revised test case which works correctly --- Bug imported by sgothel@jausoft.com 2010-03-24 07:46 EDT --- This bug was previously known as _bug_ 54 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=54 Imported an attachment (id=14) Imported an attachment (id=15) The original submitter of attachment 14 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com. The original submitter of attachment 15 [details] is unknown. Reassigning to the person who moved it here: sgothel@jausoft.com.