Re: OSX Lion issues (PBuffers)
Posted by Sven Gothel on Aug 04, 2012; 11:27pm
URL: https://forum.jogamp.org/OSX-Lion-issues-PBuffers-tp4021385p4025756.html
On 08/05/2012 12:41 AM, Moa [via jogamp] wrote:
> 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
>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.
>
URL: https://forum.jogamp.org/OSX-Lion-issues-PBuffers-tp4021385p4025756.html
On 08/05/2012 12:41 AM, Moa [via jogamp] wrote:
> 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
>
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.
>
signature.asc (910 bytes) | Free forum by Nabble | Edit this page |