---- Reported by tomas_hamala 2006-10-24 03:02:31 ----

Our program uses GLJPanel. This works well on most computers (Windows, Linux and
MacOS X). However, on at least one computer this fails with an exception:
javax.media.opengl.GLException: Error releasing pbuffer device context: error code 0

The top of the stacktrace is as follows:
com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.destroy(WindowsPbufferGLDrawable.java:92)
com.sun.opengl.impl.GLPbufferImpl$DestroyAction.run(GLPbufferImpl.java:253)
com.sun.opengl.impl.GLPbufferImpl.destroy(GLPbufferImpl.java:179)
...

Running in debug mode (-Djogl.debug) the output immediatly preceding the crash is:
Created pbuffer 256 x 256
AWT-EventQueue-1: !!! Destroyed OpenGL context 0x20000
GLJPanel.handleReshape: (w,h) = (437,807)
Resizing pbuffer from (256, 256)  to fit (437, 807)

The computer in question runs an AMD Sempron 3000+ on an ASRock K7S41GX
motherboard with an SiS chipset (and onboard GPU). I tried updating the graphics
drivers to the latest version, but it didn't change anything.

This behaviour goes for the demos on https://jogl-demos.dev.java.net/ too:
The demos that use GLCanvas work fine, while the ones with GLJPanel just crash
without any feedback. For example Gears works, but selecting Gears in JRefract
causes the demo to crash.



---- Additional Comments From tomas_hamala 2006-10-25 07:15:07 ----

Below is a minimal test case. If you run it without parameters (on the mentioned
computer) it crashes when the window is resized. If you run it with a parameter
(meaning JCanvas is used), it doesn't crash.

import javax.swing.JFrame;
import javax.media.opengl.GLJPanel;
import javax.media.opengl.GLCanvas;
import java.awt.Dimension;

public class TestGLJPanel extends JFrame {
  private TestGLJPanel(final boolean useCanvas) {
    super();
    if(useCanvas) {
      System.out.println("Using GLCanvas");
      add(new GLCanvas());
    } else {
      System.out.println("Using GLJPanel");
      add(new GLJPanel());
    }
    setSize(new Dimension(250,250));
    setVisible(true);
    setDefaultCloseOperation(EXIT_ON_CLOSE);
  }

  public static void main(final String[] args) {
    new TestGLJPanel(args.length>0);
  }
}




---- Additional Comments From kbr 2006-10-25 10:28:09 ----

I'm sorry, but I can't reproduce this problem. It is pretty clearly a problem
with the SiS OpenGL drivers, which we have found from experience and users'
reports to be very poor in quality. I don't have a good recommendation aside
from either trying to file a bug with the vendor or to upgrade to a computer
with a better chipset (at least ATI, but NVidia recommended). You may also want
to try using LWJGL to see if you get any better behavior out of that library. If
you do, please reopen this bug and provide the LWJGL test case as well.




---- Additional Comments From tomas_hamala 2006-10-26 05:07:29 ----

Lwjgl isn't really an option as it, as far as I can see, only offers an AWT
Canvas (which already works in jogl) and not a swing JPanel. So testing that
wouldn't give any more information.

Upgrading the computer is not really a good option either, because we'd rather
not force our customers to upgrade their hardware unless it's really necessary.

I found out that this works if you run jogl without hardware acceleration, by
specifying -Djogl.gljpanel.nohw. If it was possible to do this in the program it
would be great, because then we could just catch any GLException and recreate
the offending JPanel without hardware acceleration.
(Just setting setHardwareAccelerated(false) on GLCapabilities does nothing,
hardware acceleration seems to always be preferred.)

Finally, the documentation for GLJPanel says "This component attempts to use
hardware-accelerated rendering via pbuffers and falls back on to software
rendering if problems occur." So even if it is the SiS drivers that are to
blame, GLJPanel should really handle this better, in my opinion.




---- Additional Comments From kbr 2006-10-26 07:09:28 ----

Good points. It has been so long since I've diagnosed a problem that I'd
forgotten about the option to use Windows DIB sections rather than pbuffers.
I've reopened this issue and will try to implement the fallback path you've
described soon.




---- Additional Comments From kbr 2006-11-14 23:45:38 ----

A workaround for the reported issue has been added to the GLJPanel
class and tested by forcing GLPbuffer.destroy() to throw a
GLException. The new fallback path appears to be working correctly.
Please reopen this issue or file a new one if this doesn't appear to
be the case.

The fix is in the JOGL source tree and will be in nightly builds dated 11/15 or
later; note that the nightly builds will be down for a few days due to the
machines being moved.




---- Additional Comments From tomas_hamala 2006-11-30 05:28:58 ----

Well, I tested it now, and it seems there's still a problem. It does not crash
anymore, but instead it renders a completely black panel. I get this behaviour
both from our program, the jogl demos which use GLJPanel, as well as the above
test program (to which I just added a GLEventListener which renders a quad.)

I'm unsure of how I could test this further. Debugging the program shows that
the display method of the GLEventListener is being called, but for some reason
the results do not show up on screen.

If there are any other tests I could make to help resolve this, please tell me.
Otherwise, I suppose a black window is better than an exception ;)



---- Additional Comments From tomas_hamala 2006-11-30 07:40:01 ----

Sorry, it seems someone has tried to fix the problem on this computer by
installing new graphics drivers. When I reverted to the correct ones (the ones I
used last time I tested), it started working.

So thanks for the help, and sorry for reopening this again :)



---- Additional Comments From kbr 2006-12-01 01:12:23 ----

Marking as fixed again per submitter's feedback.




--- Bug imported by sgothel@jausoft.com 2010-03-24 07:49 EDT  ---

This bug was previously known as _bug_ 248 at https://jogl.dev.java.net/bugs/show_bug.cgi?id=248