GLException: Unable to select GLCapabilities

Ophir · December 9, 2004, 4:44pm

I am converting my code to JOGL from GL4Java. I am getting an error at runtime for the following test code. Do I need to create a custom glCap to pass in? I’m running Win2K with a 3Dlabs Wildcat II 5110 at 1600x1200, 32 bit. JDK 1.5.0, JOGL 1.1b07 - November 19

GLCanvas canvas =
GLDrawableFactory.getFactory().createGLCanvas(
new GLCapabilities());

Frame testFrame = new Frame(“TestFrame”);
testFrame.setSize( 512, 384 );
testFrame.add( canvas );
testFrame.setVisible(true);

Exception in thread “main” net.java.games.jogl.GLException: Unable to select one of the provided GLCapabilities
at net.java.games.jogl.DefaultGLCapabilitiesChooser.chooseCapabilities(DefaultGLCapabilitiesChooser.java:214)
at net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext(WindowsGLContext.java:471)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.create(WindowsOnscreenGLContext.java:211)
at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(WindowsGLContext.java:135)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.makeCurrent(WindowsOnscreenGLContext.java:110)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:250)
at net.java.games.jogl.GLCanvas.reshape(GLCanvas.java:112)
at java.awt.Component.setBounds(Component.java:1847)
at java.awt.BorderLayout.layoutContainer(BorderLayout.java:809)
at java.awt.Container.layout(Container.java:1401)
at java.awt.Container.doLayout(Container.java:1390)
at java.awt.Container.validateTree(Container.java:1473)
at java.awt.Container.validate(Container.java:1448)
at java.awt.Window.show(Window.java:507)
at java.awt.Component.show(Component.java:1300)
at java.awt.Component.setVisible(Component.java:1253)

kbr · December 9, 2004, 7:02pm

Do you have the ability to rebuild the JOGL source tree? If so, could you change the DEBUG flag in DefaultGLCapabilitiesChooser to true and rerun (or clone that particular class in your own source base and enable the debugging code)? Alternatively, look in the JOGL Issue Tracker for the patch to use Mojang’s ScoreCapabilitiesChooser, which might have a more robust selection algorithm than the DefaultGLCapabilitiesChooser. Sorry about this. You shouldn’t have to create a custom GLCapabilities object or your own GLCapabilitiesChooser in order to get a basic window to come up. Once we figure out what’s going wrong hopefully you could file a bug with the JOGL Issue Tracker.

Ophir · December 9, 2004, 10:36pm

OK, I finally got it to compile and run (after struggling with signed Jar security exceptions and getting the paths to the source and jars straight in JBuilder). Here is the output:

Available 0: null
Available 1: null
Available 2: null
Available 3: null
Available 4: null
Available 5: null
Available 6: null
Available 7: null
Available 8: null
Available 9: null
Available 10: null
Available 11: null
Available 12: null
Available 13: null
Available 14: null
Available 15: null
Available 16: null
Available 17: null
Available 18: null
Available 19: null
Available 20: null
Available 21: null
Available 22: null
Available 23: null
Available 24: null
Available 25: null
Available 26: null
Available 27: null
Available 28: null
Available 29: null
Available 30: null
Available 31: null
Available 32: null
Available 33: null
Available 34: null
Available 35: null
Available 36: null
Available 37: null
Available 38: null
Available 39: null
Available 40: null
Available 41: null
Available 42: null
Available 43: null
Available 44: null
Available 45: null
Available 46: null
Available 47: null
Available 48: null
Available 49: null
Available 50: null
Available 51: null
Available 52: null
Available 53: null
Available 54: null
Available 55: null
Available 56: null
Available 57: null
Available 58: null
Available 59: null
Available 60: null
Available 61: null
Available 62: null
Available 63: null
Available 64: null
Available 65: null
Available 66: null
Available 67: null
Available 68: null
Available 69: null
Available 70: null
Available 71: null
Available 72: null
Available 73: null
Available 74: null
Available 75: null
Available 76: null
Available 77: null
Available 78: null
Available 79: null
Available 80: null
Available 81: null
Available 82: null
Available 83: null
Scores: [ -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999, -9999999 ]

kbr · December 9, 2004, 11:12pm

That looks pretty bad. The only thing I can think of is that somehow either wglGetPixelFormatAttribivARB or DescribePixelFormat is indicating that the pixel formats don’t support OpenGL rendering. Would you be willing to instrument net.java.games.jogl.impl.windows.WindowsGLContext.choosePixelFormatAndCreateContext and in particular iattributes2GLCapabilities and pfd2GLCapabilities to see why the latter two routines are returning null for the GLCapabilities object?

Ophir · December 10, 2004, 2:35pm

I’m stepping through WindowsGLContext in the debugger. I assume that’s what you meant for me to do. pfd2GLCapabilities never gets called. In iattributes2GLCapabilities, for formats 0-59, it returns null for the code

    case GL.WGL_SUPPORT_OPENGL_ARB:
      if (iresults[i] != GL.GL_TRUE)
        return null;
      break;

because
iresults[7] == 8236

For formats 60-83, it returns null for the code

    case GL.WGL_DRAW_TO_WINDOW_ARB:
      if (iresults[i] != GL.GL_TRUE)
        return null;
      break;

because
iresults[0] == 0

Let me know what other information I can provide.
Thanks for helping.

kbr · December 10, 2004, 10:03pm

Wow, a Java debugger. Haven’t used one of those in a while. I’m too used to emacs and javac on the command line.

What happens if you change the logic to


        case GL.WGL_SUPPORT_OPENGL_ARB:
          if (iresults[i] == GL.GL_FALSE)
            return null;
          break;

Incidentally, the fact that requireRenderToWindow isn’t tested in the WGL_DRAW_TO_WINDOW_ARB case is a bug.

Ophir · December 10, 2004, 10:55pm

I changed both of the tests to the form you suggested, but formats 0-59 now fail the test


case GL.WGL_PIXEL_TYPE_ARB:
    if (iresults[i] != GL.WGL_TYPE_RGBA_ARB)
        return null;
    break;

because iresults[7] == 8236

According to wglext.h,

GL.WGL_TYPE_RGBA_ARB == 0x202B == 8235
WGL_TYPE_COLORINDEX_ARB == 0x202C == 8236

Formats 60-83 now fail the test


case GL.WGL_DRAW_TO_WINDOW_ARB:
    if (iresults[i] == GL.GL_FALSE)
        return null;
    break;

because iresults[0] == 0

Ophir · December 10, 2004, 11:45pm

Since the result returned didn’t match, I wondered if there coud be a problem with the display driver. I upgraded it from version 05050335 to 05050618, rebooted and, sure enough, my window popped up. iresult is now 8235 and it passes the test. My new output is:

Choosing window system’s recommended choice of 0

GLCapabilities [DoubleBuffered: true, Stereo: false, HardwareAccelerated: true, DepthBits: 32, StencilBits: 0, Red: 8, Green: 8, Blue: 8, Alpha: 0, Red Accum: 0, Green Accum: 0, Blue Accum: 0, Alpha Accum: 0 ]

Sorry I didn’t try that sooner. Thanks for the help.