(Originally posted in http://forum.jogamp.org/Context-sharing-between-offscreen-drawable-and-external-GL-context-td4034536.html)
My setup is as follows. I have a Java library which renders into an offscreen drawable. This library needs to be integrated into a native host application (C++, C#, ...). To do so, the Java code renders into a texture, which I then want to make available to a GL context created by the native code. I set this up as follows:
* The native code creates a GL context and makes it current
* The Java code creates an external GL context (corresponding to the native one)
* On a different thread, the Java code then creates an offscreen drawable which shares with the external GL context
For various reasons, it would be convenient if the "different thread" above could be the EDT. However, on Windows systems with NVidia GPUs, that doesn't work. After the offscreen drawable is created, the first call to display() results in an exception:
com.jogamp.opengl.GLException: AWT-EventQueue-0: createImpl ctx !ARB but ARB is used, profile > GL2 requested (OpenGL >= 3.1). Requested: GLProfile[GL4bc/GL4bc.hw], current: 4.5 (Compat profile, compat[ES2, ES3, ES31], FBO, hardware) - 4.5.0 NVIDIA 347.52
When I use a dedicated (non-EDT) thread, this error does not occur. On an AMD GPU, either approach works fine.
I have a unit test for this issue, which I will also submit (ShareWithExternalContextTest).
So far the unit test passes, while using AWT-EDT
invoke later, not blocking the current GLEventListener.
However, this exposes a weakness in sharing w/ an external context,
since we cannot guarantee the state of the external master context.
The latter should be locked while creating the slave context,
which is guaranteed if using pure JOGL context/drawable semantics.
Note: The non AWT-EDT path in the test is also non-blocking.
Hence the result is sort of unstable, even if it passes.
You will also note the 'masterLock' in the test code,
which does _not_ work when using AWT-EDT - reason unknown.