OSX Lion issues (PBuffers)

I have been chasing a bug that appears to affect only OSX Lion with integrated Radeon video cards (the details are available in this bug entry: https://jogamp.org/bugzilla/show_bug.cgi?id=569).

I think the reason for this bug is the fact that PBuffers have been deprecated in OSX 10.7 (as indicated in this release notes: http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html), so they are starting to behave unreliably.

I have a couple of observations/questions related to this issue:

1) I tried to enable the onscreen/no pbuffer path by setting my GLCapabilities with setOnscreen(true). However, JOGL apparently still tries to use offscreen rendering with pbuffers. Is there any reason for this? Is the onscreen rendering path non-functional at this time, or should I do some other additional initialization steps?

2) With PBuffers deprecated already, the situation would probably deteriorate even further in OSX 10.8. The natural replacement for PBuffers are FBOs, so is there any plan to replace the native pbuffer offscreen implementation in JOGL with an equivalent FBO-based counterpart? This is particularly important for me to know, because this issue is kind of a deal breaker in Processing since a large portion of users are on the OSX platform.

Thanks!

(small correction: above I meant "dedicated" Radeon video cards)

After installing OSX 10.8, my (OSX 10.7 previously working) program crashes at launch with:

2012-07-26 23:47:22.769 java[2510:12a07] -[NSViewAWT CGLPBufferObj]: unrecognized selector sent to instance 0x7fd1e3cb0510
2012-07-26 23:47:22.769 java[2510:12a07] An uncaught exception was raised
2012-07-26 23:47:22.770 java[2510:12a07] -[NSViewAWT CGLPBufferObj]: unrecognized selector sent to instance 0x7fd1e3cb0510
2012-07-26 23:47:22.770 java[2510:12a07] (
        0   CoreFoundation                      0x00007fff95627716 __exceptionPreprocess + 198
        1   libobjc.A.dylib                     0x00007fff900c6470 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff956bdd5a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
        3   CoreFoundation                      0x00007fff95615c3e ___forwarding___ + 414
        4   CoreFoundation                      0x00007fff95615a28 _CF_forwarding_prep_0 + 232
        5   AppKit                              0x00007fff8b553b3e -[NSOpenGLContext setPixelBuffer:cubeMapFace:mipMapLevel:currentVirtualScreen:] + 59
        6   libjogl_desktop.jnilib              0x000000011910b89b setContextPBuffer + 203
        7   libjogl_desktop.jnilib              0x000000011916f29b Java_jogamp_opengl_macosx_cgl_CGL_setContextPBuffer__JJ + 43
        8   ???                                 0x00000001052f3d6e 0x0 + 4381949294
        9   ???                                 0x00000001052e885a 0x0 + 4381902938
        10  ???                                 0x00000001052e8e03 0x0 + 4381904387
        11  ???                                 0x00000001052e8929 0x0 + 4381903145
)
2012-07-26 23:47:22.771 java[2510:12a07] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSViewAWT CGLPBufferObj]: unrecognized selector sent to instance 0x7fd1e3cb0510'
*** First throw call stack:
(
        0   CoreFoundation                      0x00007fff95627716 __exceptionPreprocess + 198
        1   libobjc.A.dylib                     0x00007fff900c6470 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff956bdd5a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
        3   CoreFoundation                      0x00007fff95615c3e ___forwarding___ + 414
        4   CoreFoundation                      0x00007fff95615a28 _CF_forwarding_prep_0 + 232
        5   AppKit                              0x00007fff8b553b3e -[NSOpenGLContext setPixelBuffer:cubeMapFace:mipMapLevel:currentVirtualScreen:] + 59
        6   libjogl_desktop.jnilib              0x000000011910b89b setContextPBuffer + 203
        7   libjogl_desktop.jnilib              0x000000011916f29b Java_jogamp_opengl_macosx_cgl_CGL_setContextPBuffer__JJ + 43
        8   ???                                 0x00000001052f3d6e 0x0 + 4381949294
        9   ???                                 0x00000001052e885a 0x0 + 4381902938
        10  ???                                 0x00000001052e8e03 0x0 + 4381904387
        11  ???                                 0x00000001052e8929 0x0 + 4381903145
)
libc++abi.dylib: terminate called throwing an exception

Tried setting pbuffer to false explicitly in the capabilities given to the GLCanvas constructor, to no avail.

Weirdly enough, switching to GLJPanel fixes the problem. Both NewtCanvasAWT and GLCanvas have the problem.

Lukasz,

I ran into this strange problem on Mountain Lion too. If I have the following:

    GLProfile glp = GLProfile.get(GLProfile.GL2);
    GLCapabilities glc = new GLCapabilities(glp);
    GLCanvas canvas = new GLCanvas(glc);
    canvas.addGLEventListener(new Test());
    
    JFrame window = new JFrame("faosidjf");
    window.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    window.setSize(800,600);
    window.add(canvas);
    window.setVisible(true);

... I get the same crash as you have above. This is fixed if I enabled multisampling on the GLCanvas:

glc.setSampleBuffers(true);

Thanks for the tip JStoecker. However, I still prefer to use GLJPanel for the time being, since even when setting NumSamples to 1, there is still a bit of multisampling occurring which smudges the crispness of the plot lines in my program.

Thanks for the tips guys.

I too am using a GLCanvas and get the same exception as Lucasz.  I am also using multisampling, but this does not help in my case.

My code used to work correctly on OS X 10.7.4 (Lion) but has broken once moving to OS X 10.8 (Mountain Lion). My JoGL code still works on Windows and Linux.

Trying the GLJPanel suggestion this doesn't work for me either. I get messages the following:
javax.media.opengl.GLException: Context not current on current thread AWT-EventQueue-0: MacOSXPbufferCGLContext [OpenGL 2.1
Note that with GLJPanel this is not being called as a result of a call to display()  [as I said, I ensure the context is current in this case], but is instead called when the panel gets a paintComponent() event. I tried overriding the GLJPanel to fix the problem with paintComponent() but find that the derived class never gets init() called. So I'm wondering whether GLJPanel is designed for inheritence or not?

Please also note that I also get the "context not current" message on Windows and Linux but they still render, on Mac Mountain Lion it does not render. Note: I'm not using the JoGL Animator classes (I notice there is some dependency inside GLCanvas and GLJPanel on whether an animator is registered or not, this seems a little backward, but I'm new to JoGL 2.0rc9 so perhaps there's something I'm missing?).

To summarize, these are the issues I'm having since moving to Mountain Lion (and JoGL 2.0rc9):
1) Using GLCanvas on the Mac fails with an exception stating that an unrecognized selector has been passed to the PBuffer.

2) Using GLJPanel fails with a "context not current" warning, and does not render.

3) Using GLCanvas on Windows and Linux renders, but the "context not current" warning is still given.

4) Using GLCanvas with an earlier version of JoGL (beginning of year, sorry don't know release number) worked on Mac, Windows, Linux without "context not current warnings".

5) Using the suggested workarounds of GLJPanel and multisampling with GLCanvas don't work for me.


I'm happy to help in any way I can (full stack traces, try anything out etc), and thanks to everyone who has made suggestions already.


Environment:
Hardware: 17" MacBook Pro mid 2009  (5,2)
Graphics: NVidia GeForce 9600M GT  
OS X version: 10.8
JoGL version: 2.0rc9

Windows/Linux graphics: ATI Radeon 5970

On 07/30/2012 09:16 AM, JStoecker [via jogamp] wrote: Can you test w/ latest code ?
If you cannot compile JOGL, pls try w/ latest RC build aggregated here:
  <http://jogamp.org/deployment/archive/rc/gluegen_49-joal_29-jogl_60-jocl_38/>
and signed here:
  <http://jogamp.org/deployment/archive/rc/gluegen_49-joal_29-jogl_60-jocl_38-signed/>

Note: This is not yet RC10!

The changeset includes a fix to capabilities settings of alpha & msaa,
however, I am unsure if this is related.

~Sven

I tried that patch Sven and got the exact same behaviour:

+ GLJPanel produces: "context not current" exceptions in paintComponent() calls, and
+ GLCanvas produces:  "[NSViewAWT CGLPBufferObj]: unrecognized selector sent to instance ..."

On 08/02/2012 12:10 PM, Moa [via jogamp] wrote:
> I tried that patch Sven and got the exact same behaviour:
>
> + GLJPanel produces: "context not current" exceptions in paintComponent()
> calls, and
> + GLCanvas produces:  "[NSViewAWT CGLPBufferObj]: unrecognized selector sent
> to instance ..."
>

I am afraid you have to wait until
Bug 569 and Bug 599 gets fixed - looks like pbuffer is no more reliable w/
that OSX version.
Should be done in about 2 weeks.

~Sven

Thanks for the approximate ETA Sven .. and for all your hard work.

One question, when trying a workaround for this pbuffer problem I noticed that deriving a class from GLJPanel meant that the init() method didn't get called. Do you have any idea why a derived class might not have init() called when the same code works for the base class (GLJPanel) ?

backend.preGL(Graphics) returns false in your case, look at the source code on Github to see what I mean.

After some experimentation I can confirm that the suggestion by Lucasz to use GLJPanel rather than GLCanvas works for me.

I was having a problem with "Context not Current" messages after upgrading to JoGL 2.0 rc9 (and the pre-rc10 Sven posted here). The problem I had was not related to pbuffers (but was due to the JoGL components not ensuring they have a valid context before proceeding, which I suggest the JoGL maintainers look at to make things a lot more robust).

Here is a link to the forum post describing the issue and resolution in more detail:
http://forum.jogamp.org/Error-Making-Context-Current-JOGL-2-0-rc9-td4025517.html#a4025754

Meanwhile, I believe the state of play is (for anyone new trying to follow this thread):
 
  * on Windows, Linux and Mac OS X 10.7 (Lion) both the GLCanvas and GLJPanel can be used without issue.
 
  * on Mac OS X 10.8 (Mountain Lion) the GLJPanel can be used without issue.

  * on Mac OS X 10.8 (Mountain Lion) the GLCanvas cannot be used. This is due to Apple changing pbuffer support. Sven is working on a replacement using FBOs but this will not be ready for two weeks from the time of writing (since he's busy with his commitment to the SIGGRAPH conference).

  * on Mac OS X 10.8 the Newt may or may not be usable (I haven't tested this myself).

  * on all platforms the paintComponent() methods (or equivalent) do not ensure that the GL context is bound to the current thread, which can cause problems. This means that clients should never call GLContext's releaseContext() method in the display(GLAutoDrawable) callback when using JoGL 2.0 rc9 or later. It is still ok to call GLContext's makeCurrent() method in display().

I hope that is helpful to other readers.

ps. thanks for the suggestion gouessej. It turns out I don't need to derive a class from GLJPanel to fix paintComponent() any more, so I won't need to investigate that avenue further.

On 08/05/2012 12:41 AM, Moa [via jogamp] wrote: I just glanced on your code in above posting
and reading your statement:

>   * on all platforms the paintComponent() methods (or equivalent) do not
> ensure that the GL context is bound to the current thread, which can cause
> problems. This means that clients should never call GLContext's
> releaseContext() method in the display(GLAutoDrawable) callback when using
> JoGL 2.0 rc9 or later. It is still ok to call GLContext's makeCurrent() method
> in display().

rang a bell.

init(GLAutoDrawable), display(GLAutoDrawable), ..
are GLEventListener methods. As you can read in the API doc,
the context _is_ current when they are being called,
assuming your GLEventListener implementation is registered via
'addGLEventListener(..)' with the GLAutoDrawable (GLCanvas, GLJPanel).
Please validate with the many unit test we have, i.e. GearsES2.

One shall never issue makeCurrent() or release() on the current context
within the GLEventListener implementation (display, init, ..).

> Meanwhile, I believe the state of play is (for anyone new trying to follow
> this thread):
>  
>   * on Windows, Linux and Mac OS X 10.7 (Lion) both the GLCanvas and GLJPanel
> can be used without issue.
Ack.

>  
>   * on Mac OS X 10.8 (Mountain Lion) the GLJPanel can be used without issue.
Ok (good to know).

>
>   * on Mac OS X 10.8 (Mountain Lion) the GLCanvas cannot be used. This is due
> to Apple changing pbuffer support. Sven is working on a replacement using FBOs
> but this will not be ready for two weeks from the time of writing (since he's
> busy with his commitment to the SIGGRAPH conference).
Yup.

>
>   * on Mac OS X 10.8 the Newt may or may not be usable (I haven't tested this
> myself).
NEWT should work.

~Sven

>
>
> I hope that is helpful to other readers.
>
> ps. thanks for the suggestion gouessej. It turns out I don't need to derive a
> class from GLJPanel to fix paintComponent() any more, so I won't need to
> investigate that avenue further.
>

Hey guys never posted but just realized something with this exact exception - if i am on integrated graphics only, I get the exception. If not, I can run with a GLCanvas on Mountain Lion no prob bob.

FWIW..

Can you be more precise about the graphics hardware?

Sorry -

This is a MacBook Pro Retina -

Integrated graphics: Intel 4000
Discrete: NVIDIA GeForce GT 650M 1024 MB

I have a java based JOGL app I wrote that has functioned fine for a long time, started it on my laptop yesterday and got this every time I ran it:

2012-09-15 20:46:11.498 java[1365:15007] (
        0   CoreFoundation                      0x00007fff8686d716 __exceptionPreprocess + 198
        1   libobjc.A.dylib                     0x00007fff8a360470 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff86903d5a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
        3   CoreFoundation                      0x00007fff8685bc3e ___forwarding___ + 414
        4   CoreFoundation                      0x00007fff8685ba28 _CF_forwarding_prep_0 + 232
        5   AppKit                              0x00007fff89a63b3e -[NSOpenGLContext setPixelBuffer:cubeMapFace:mipMapLevel:currentVirtualScreen:] + 59
        6   libjogl_desktop.jnilib              0x000000011a7337db setContextPBuffer + 203
        7   libjogl_desktop.jnilib              0x000000011a79315b Java_jogamp_opengl_macosx_cgl_CGL_setContextPBuffer__JJ + 43
        8   ???                                 0x000000010b849eee 0x0 + 4488208110
        9   ???                                 0x000000010b83e85a 0x0 + 4488161370
        10  ???                                 0x000000010b83ee03 0x0 + 4488162819

Eventually realized integrated graphics were being used (I'm using gfxCardStatus 2.1.1)  for some reason - switched to discrete, app ran fine no issues.

FYI Just to be sure I'm not spewing bad information, just tried again this morning and same thing - on integrated HD4000 graphics it happens, on discrete gt650 the JOGL app runs with no problems. I changed nothing else between the two runs.

You're the second person to report specific problems with integrated graphics chips under recent Mac OS X.

FYI JoGL application works on 10.7.4 on a 2011 imac 27" (with radeon AMD Radeon HD 6970M 1024 MB) but crashes on 10.7.5. Identical macs at work.