Login  Register

Re: GLCanvas in CardLayout

Posted by Sven Gothel on Dec 09, 2011; 2:04pm
URL: https://forum.jogamp.org/GLCanvas-in-CardLayout-tp3571796p3572963.html

On Friday, December 09, 2011 01:46:27 PM gouessej [via jogamp] wrote:
>
> Someone else has a similar problem here but with an NVidia graphics card:
> http://www.ardor3d.com/forums/viewtopic.php?f=10&t=4300&p=13525#p13525
> http://www.ardor3d.com/forums/viewtopic.php?f=10&t=4300&p=13525#p13525 
>

I see, 'Sie sprechen Deutsch' - your German is very good.
My French is lousy and almost forgot all of it and had only a bit of a year in school
before I 'cancelled' it :( Now, I try to learn Chinese .. well, another attempt for failure :)

Ok .. back to the issue.

The exception thrown:

+++

Exception in thread "main" javax.media.opengl.GLException: Unable to create temp OpenGL context for device context 0x201206f
        at jogamp.opengl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:294)

+++

Is _after_ the SharedResourceRunner successfully established a GL 3.3 context and made it current.

Then your AWT Canvas 'thingy' attempts to create the context, where the ARB method fails
and the fallback:
  WindowsWGLContext.java:292 temp_ctx = WGL.wglCreateContext(drawable.getHandle());
fails as well.

My only conclusion here is that the native drawable handle is not valid,
probably it's not configured properly (HDC/PFD -> WindowsWGLGraphicsConfiguration.setPixelFormat(..)).
Please double check our 'validateGLDrawable()' usage as noted below.

Sorry that I have no time right now to review your 'JoglAwtCanvas' impl. but I hope these explanations
help to solve the problem, since IMHO this bug is not related to the OpenGL driver.
I may have time in one week to get my hands on it, well .. sorry.

Another thought is .. wouldn't it be possible to simple inherit from our GLCanvas ?
(Since it's impl. is proven so far .. and impl. the AWT 'hook' is a horrible task)

Here is what I have send to another person about JOGL's GLCanvas
and it's initialization sequence .. since it's very tricky - to say the least:

+++

addNotify() {
  drawable.lock() {
        awtConfig = chooseGraphicsConfiguration(capsReqUser, capsReqUser, chooser, device);
        if(null==awtConfig) {
            throw new GLException("Error: NULL AWTGraphicsConfiguration");
        }

        drawable = GLDrawableFactory.getFactory(capsReqUser.getGLProfile())
                           .createGLDrawable(NativeWindowFactory.getNativeWindow(this, awtConfig));
        context = (GLContextImpl) drawable.createContext(shareWith);

        ...

        // before native peer is valid: X11
        disableBackgroundErase();

        // issues getGraphicsConfiguration() and creates the native peer
        super.addNotify();

        // after native peer is valid: Windows
        disableBackgroundErase();
  } drawable.unlock();
}

The path of initialize the AWT GraphicsConfiguration along w/ the AWT NativeWindow (JAWTWindow)
is very sensitive to say the least.

Notes:

'validateGLDrawable()' issues 'drawable.setRealized(true)', ie updates and finalizes
the AbstractGraphicsConfiguration, eg. WindowsWGLGraphicsConfiguration - including the call
to WindowsWGLGraphicsConfiguration.setPixelFormat(..)!!

'validateGLDrawable()' is invoked in the AWT Canvas's display() method and only proceeds if
the AWT native peer size is > 0x0. Attempts to issue this at addNotify() may fail, since the
native peer (HDC) is not yet established completly (or something like that).


The call 'NativeWindowFactory.getNativeWindow(this, awtConfig)' generates a NativeWindow impl. JAWTWindow
wich is then used as the agnostic interface for the GLDrawable implementation.

The 'awtConfig' must be chosen before calling 'super.addNotify()' of the AWT Canvas/Component
since it's being used for it's native creation. The latter gets the AWT GraphicsConfiguration
w/ out overridden 'public GraphicsConfiguration getGraphicsConfiguration()', which itself
utilizes our 'awtConfig' and check for compatibility.

+++

~Sven