Posted by Sven Gothel on May 09, 2012; 3:15am
URL: https://forum.jogamp.org/GLWindow-setSize-exception-upgrading-to-rc8-tp3966421p3973072.html

On 05/08/2012 09:25 AM, jouvieje [via jogamp] wrote:
> I have tested using a GLAnimationControl to register my own RenderLoop, and
> the freeze is in fact gone with that.
Great to hear.

> One question about GLAnimationControl, is it necessary to implements
> FPSCounter methods ? Returning 0 to all fps getter seem to work fine, but I'm
> wondering if it's ok do to that.
Since you are the 'user' of your implementation, it's OK of course.
You can also utilize 'FPSCounterImpl' from within your implementation
as it is currently used in GLAnimator etc.

>
> Basically, my setup is a NewtCanvasAWT inside a frame/jframe. RenderLoop calls
> GLWindow.display in it's own thread. The frame is resize in some other thread
> I've created. And it seem AWTParentWindowAdapter runs the newt window resize
> in it's own EDT thread, which seems to dislike my RenderLoop locking the surface.
>
I already have thought about the root cause and it seems to be a regression
of GLWindow related to the NativeSurface/GLContext lock order.

GLContext.makeCurrent() locks in the following order:
  1 - GLContext
  2 - GLDrawable/NativeSurface

where the NativeSurfaces (Window, GLWindow, ..) lock only itself.

The makeCurrent() cannot complete, since the NativeSurface is already locked
by another thread. If it would have waited for the NativeSurface lock before
claiming the context lock no stavation would occur.

GLContext shall always lock it's surface 1st,
then it's own lock. The latter depends on the former and is the natural
locking order which plays along w/ other use-cases like resize.

This implies that the 'GLContext.setSynchronized(false)' case is somewhat
unusable, since we should hold the NativeSurface lock first.

> I'll try to write a test case to reproduce this freeze.
> Would it be usefull to you if I send you the binary of my application which
> reproduce the freeze ?

Thank you Jerome, I guess it's not necessary since the starvation / deadlock
is understood now. I will provide a fix w/ unit tests soon.

~Sven

> Jérôme