Bug 54 - No GL listener callbacks when setting render thread before window is visible
Summary: No GL listener callbacks when setting render thread before window is visible
Status: VERIFIED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: core (show other bugs)
Version: 1
Hardware: All windows
: P3 normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2003-11-25 04:21 CET by Sven Gothel
Modified: 2010-03-24 07:46 CET (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
Workaround: ---


Attachments
Complete test case (11.75 KB, text/plain)
2005-01-26 13:08 CET, Sven Gothel
Details
Revised test case which works correctly (12.26 KB, text/plain)
2005-01-27 18:58 CET, Sven Gothel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2010-03-24 07:46:07 CET


---- 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.