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