Error Making Context Current JOGL 2.0 rc9

I've got a JOGL 2.0 application and I'm getting a very repeatable "Error making context current: 0x0x20000" error.  It only happens when the OpenGL window is created on my second monitor (which ever one is not my main monitor in windows) - oddly enough.  I've tried making each monitor main, and it happens when I "setLocation" of the JFrame to the OTHER monitor.

Any thoughts on what might be causing this?  I've seen a lot of posts like this that are older, but the answer is always: "the bug was fixed, use the latest version."  I am using the latest RC.

EDIT - By the way this is on a box with an ATI Radeon HD 5700 Series graphics card.  I cannot seem to reproduce this issue on any machine with an NVidia graphics card.

Here is what I get on my console:

Exception in thread "Timer-0" java.lang.RuntimeException: javax.media.opengl.GLException: Error making context current: 0x0x20000, werr: 0, WindowsOnscreenWGLContext [OpenGL 4.2, options 0x103, 4.2 (Compatibility profile, arb, ES2 compatible, hardware) - 4.2.11631 Compatibility Profile Context, handle 0x20000, jogamp.opengl.gl4.GL4bcImpl@7d91275b,
        Drawable: WindowsOnscreenWGLDrawable[Realized true,
        Factory   jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory@44af07c4,
        handle    0xffffffffb2011a77,
        Window    JAWT-Window[windowHandle 0x220c74, surfaceHandle 0xffffffffb2011a77, bounds [ 0 / 0  784 x 762 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface false, pos 0/0, size 784x762, visible true, lockedExt false,
        config AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection \Display0, unitID 0, awtDevice D3DGraphicsDevice[screen=0], handle 0x0], idx 0],
        chosen    GLCaps[wgl vid 0x2 arb: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 0/0/0/0, dp/st/ms: 24/8/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]],
        requested GLCaps[on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]],
        sun.awt.Win32GraphicsConfig@71a550f9[dev=D3DGraphicsDevice[screen=0],pixfmt=2],
        encapsulated WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0], idx 0], pfdID 2, ARB-Choosen true,
        requested GLCaps[on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]],
        chosen    GLCaps[wgl vid 0x2 arb: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 0/0/0/0, dp/st/ms: 24/8/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]]]],
        awtComponent AWT-GLCanvas[Realized true,
        jogamp.opengl.windows.wgl.WindowsOnscreenWGLDrawable,
        Factory   jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory@44af07c4,
        handle    0xffffffffb2011a77,
        Drawable size 784x762,
        AWT pos 0/0, size 784x762,
        visible true,
        AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type AWT, connection \Display0, unitID 0, awtDevice D3DGraphicsDevice[screen=0], handle 0x0], idx 0],
        chosen    GLCaps[wgl vid 0x2 arb: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 0/0/0/0, dp/st/ms: 24/8/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]],
        requested GLCaps[on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]],
        sun.awt.Win32GraphicsConfig@71a550f9[dev=D3DGraphicsDevice[screen=0],pixfmt=2],
        encapsulated WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0], idx 0], pfdID 2, ARB-Choosen true,
        requested GLCaps[on-scr, rgba 0x8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms: 16/0/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]],
        chosen    GLCaps[wgl vid 0x2 arb: on-scr, rgba 0x8/8/8/8, opaque, accum-rgba 0/0/0/0, dp/st/ms: 24/8/0, dbl, mono  , hw, GLProfile[GL4bc/GL4bc.hw]]]]],
        surfaceLock <3f26f816, 17698cbe>[count 1, qsz 0, owner <AWT-EventQueue-0>]]], lock <129719f4, 7e28ebb4>[count 1, qsz 0, owner <AWT-EventQueue-0>]]
        at jogamp.common.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:58)
        at jogamp.opengl.awt.AWTThreadingPlugin.invokeOnOpenGLThread(AWTThreadingPlugin.java:103)
        at jogamp.opengl.ThreadingImpl.invokeOnOpenGLThread(ThreadingImpl.java:206)
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:172)
        at javax.media.opengl.Threading.invoke(Threading.java:191)
        at javax.media.opengl.awt.GLCanvas.display(GLCanvas.java:404)
        at com.jogamp.opengl.util.AWTAnimatorImpl.display(AWTAnimatorImpl.java:74)
        at com.jogamp.opengl.util.AnimatorBase.display(AnimatorBase.java:142)
        at com.jogamp.opengl.util.FPSAnimator$1.run(FPSAnimator.java:128)
        at java.util.TimerThread.mainLoop(Unknown Source)
        at java.util.TimerThread.run(Unknown Source)

On 07/12/2012 07:41 PM, lukej [via jogamp] wrote:
> I've got a JOGL 2.0 application and I'm getting a very repeatable "Error
> making context current: 0x0x20000" error.  It only happens when the OpenGL
> window is created on my second monitor (which ever one is not my main monitor
> in windows) - oddly enough.  I've tried making each monitor main, and it
> happens when I "setLocation" of the JFrame to the OTHER monitor.

This scenario is expected not to work for an already realized
drawable/context because the native windowing systems
only allow this when using the 'Xinerama' setup,
which is the 'one-big-screen' setting for multi-monitor.

We can discuss how to handle it .. take care, or throw a more
appropriate error message.

To do so, please use your text and this description,
add a small [unit] test case and create a new bug entry on our bugzilla.

Thx.

~Sven

Thanks Sven.  Is there a workaround that I can use?  Whats odd is that it seems to work just fine if the window is created on my main monitor and dragged to my second monitor.

On 07/13/2012 02:55 PM, lukej [via jogamp] wrote:
> Thanks Sven.  Is there a workaround that I can use?  Whats odd is that it
> seems to work just fine if the window is created on my main monitor and
> dragged to my second monitor.
>

Oh, if thats _is_ working, JOGL/AWT should work as well.

Again .. pls provide a unit test and a detailed description of
your monitor/screen setup w/ Windows. And if possible a small unit test!

I assume it's the 'big desktop' setup .. hmm,
hence there should be no difference at all.

Pls also try to do this w/ NEWT, i.e. set the location
of the NEWT window to your 2nd monitor which is not your 'main' monitor.
We have reports here it works fine - and me tested this in one virtual machine.

~Sven

Sven,
I haven't had a chance to try newt yet, but here is a single class example that shows my problem.  It's not a JUnit test because frankly...I'm not sure what I'd assert on.  The exception happens, is caught, and is displayed all outside of my code.  Short of parsing the console and looking for exceptions I'm not sure how to turn it into a true unit test.

Here is the code: JoglTestApp.java

The app puts a JOGL window in the upper left corner of each monitor.  When I run this, I get the exception from my original post.  I have an ATI Radeon HD 5700 Series graphics card.  I have also tested it on machines with an NVidia graphics card and the issue does not seem to happen.

Occasionally (very infrequently) the application does run without any issues.  Running it again almost always causes it to break and throw the exception.

EDIT:
Ok I tried NEWT too and it throws a similar exception.  The only real difference in the code (aside from the obvious) is that I added 100 to the x and y positions because GLWindow.setPosition does not function like JFrame.setLocation.  GLWindow.setPosition appears to move the top left corner of the *canvas* (vs. the window) to the position given.

JoglTestApp.java - NEWT

My Setup:
2 Samsung SyncMaster 305T monitors both running at 2560x1600 resolution.
1 ATI Radeon HD 5700 Series graphics card
Windows 7

Thanks!
Luke

In a very timely update, AMD has just released Catalyst 12.6, which seems to have made the problem go away (for one reason or another).  I was previously running Catalyst 12.4, where I observed the problem.  However, with Catalyst 12.6, everything seems to work fine.

I have this same issue with jogl 2.0 rc9 and jogl 2.0 pre-rc10. I have code that can switch between GLCanvas and GLJPanel (I don't use NEWT) and see it on both of these.

The message doesn't appear for me when display() is called, since the callback implementation is my code I can ensure that th GLContext is on the current thread. The message appears when paintComponent() is called by the system, so we don't get a chance to ensure the GLContext is current. I think fixing that case would remove the exception being thrown.

I see this same message on:
  * Windows 7 64-bit with a ATI Radeon 5970, Catalyst 12.6
  * Ubuntu 12.04 64-bit with a ATI Radeon 5970, fglrx
  * Mac OS X 10.8 (Mountain Lion), NVidia 9600M GT

I figured out what the problem was in my case.

Using JoGL from early 2012 I found I needed to render by doing something like this:

public void display(GLAutoDrawable drawable) {
    try {
      if (!drawable.getContext().isCurrent()) {
        drawable.getContext().makeCurrent();
      }
      // Do the rendering ...
    } finally {
        drawable.getContext().release();
    }
}

By the time I got around to upgrading to JoGL 2.0 rc9 I found that this code was raising a "Context not current" exception. That's when I found this thread. Now I have worked through the issue and believe I have an explanation and fix (for my code at least).

The problem here is the call to release the context. If I remove that then I can render without this "Context not current" exception successfully on Windows, Linux and Mac OS X (10.8, although GLCanvas doesn't work here due to broken Mac pbuffer support, but GLJPanel works nicely).

It appears that the paintComponent() method of JoGL don't ensure that the context is current before drawing, so if you release the context it doesn't get re-bound and the exception is raised. If any of the JoGL maintainers are reading this thread then perhaps you could consider overriding paintComponent() to acquire the GL context if doesn't have it already, that way things would be a lot more robust (IMHO) no matter what a JoGL client developer did.

To make things crystal clear, doing rendering using the following code works for me using JoGL 2.0 rc9 (and pre-rc10):

public void display(GLAutoDrawable drawable) {
    try {
      if (!drawable.getContext().isCurrent()) {
        drawable.getContext().makeCurrent();
      }
      // Do the rendering ...
    } catch (Throwable th) {
      // Log and supress/ignore the exception. Do not release the OpenGL context.
    }
}

I hope this helps someone in the future.

On 08/05/2012 12:29 AM, Moa [via jogamp] wrote: Right, see
<http://forum.jogamp.org/OSX-Lion-issues-PBuffers-tp4021385p4025756.html>
We have to evaluate this .. i.e. the above code shall not be required
or even recommended ..

If you are able to find the culprit / bug .. happy to fix it.

~Sven