Fixed Issue 274: GLException when GLJPanel (initially not visible) is made visible/showing

Investigation revealed that the symptom was similar to what happens
when one tries to create a new OpenGL context against an invalid HDC
on Windows. Discussion with Chris Campbell from the Java 2D team
indicated that in situations where the Java 2D OpenGL pipeline is
using Frame Buffer Objects for its rendering, it is possible that its
internal OpenGL context can be left current to the on-screen drawable,
and it only has a valid device context for the brief period of time
when its OpenGL context was being made current. This means that by the
time JOGL's code got a chance to run, it did not have a valid HDC and
therefore could not create its OpenGL context against it. The
workaround, suggested by Chris, is to forcibly make the Java 2D
context current against its internal "scratch" pbuffer, which can be
done with the internal invokeWithOGLSharedContextCurrent method. Added
this workaround and verified it fixes the problem with the user's test
case. This issue will be fixed in a forthcoming Java SE 6 update
release, hopefully 6u2.


git-svn-id: file:///usr/local/projects/SUN/JOGL/git-svn/svn-server-sync/jogl/trunk@1176 232f8b59-042b-4e1e-8c03-345bb8c30851

1 files changed, 33 insertions, 0 deletions

diff --git a/src/classes/javax/media/opengl/GLJPanel.java b/src/classes/javax/media/opengl/GLJPanel.java
index 3340c75d4..3e08ab079 100644
--- a/src/classes/javax/media/opengl/GLJPanel.java
+++ b/src/classes/javax/media/opengl/GLJPanel.java
@@ -184,6 +184,11 @@ public class GLJPanel extends JPanel implements GLAutoDrawable {
   private boolean checkedGLVendor;
   private boolean vendorIsATI;
 
+  // Holding on to this GraphicsConfiguration is a workaround for a
+  // problem in the Java 2D / JOGL bridge when FBOs are enabled; see
+  // comment related to Issue 274 below
+  private GraphicsConfiguration workaroundConfig;
+
   // These are always set to (0, 0) except when the Java2D / OpenGL
   // pipeline is active
   private int   viewportX;
@@ -477,6 +482,34 @@ public class GLJPanel extends JPanel implements GLAutoDrawable {
     updater.setGraphics(g);
 
     if (oglPipelineEnabled) {
+
+      // This is a workaround for an issue in the Java 2D / JOGL
+      // bridge (reported by an end user as JOGL Issue 274) where Java
+      // 2D can occasionally leave its internal OpenGL context current
+      // to the on-screen window rather than its internal "scratch"
+      // pbuffer surface to which the FBO is attached. JOGL expects to
+      // find a stable OpenGL drawable (on Windows, an HDC) upon which
+      // it can create another OpenGL context. It turns out that, on
+      // Windows, when Java 2D makes its internal OpenGL context
+      // current against the window in order to put pixels on the
+      // screen, it gets the device context for the window, makes its
+      // context current, and releases the device context. This means
+      // that when JOGL's Runnable gets to run below, the HDC is
+      // already invalid. The workaround for this is to force Java 2D
+      // to make its context current to the scratch surface, which we
+      // can do by executing an empty Runnable with the "shared"
+      // context current. This will be fixed in a Java SE 6 update
+      // release, hopefully 6u2.
+      if (Java2D.isFBOEnabled()) {
+        if (workaroundConfig == null) {
+          workaroundConfig = GraphicsEnvironment.
+            getLocalGraphicsEnvironment().
+            getDefaultScreenDevice().
+            getDefaultConfiguration();
+        }
+        Java2D.invokeWithOGLSharedContextCurrent(workaroundConfig, new Runnable() { public void run() {}});
+      }
+
       Java2D.invokeWithOGLContextCurrent(g, new Runnable() {
           public void run() {
             if (DEBUG && VERBOSE) {