GLWindow.setSize exception upgrading to rc8
Locked
GLWindow.setSize exception upgrading to rc8
 
|
Re: GLWindow.setSize exception upgrading to rc8
Administrator
|
On 05/06/2012 05:14 PM, jouvieje [via jogamp] wrote:
> I trying to upgrade to rc8 from jogl 661 > <http://jogamp.org/deployment/archive/master/gluegen_494-joal_286-jogl_661-jocl_562/>. > > > When my application is starting, the frame is resized. Now with rc8, using a > NewtCanvasAWT prevents my application from starting by the exception below > which shows up after a 5s freeze (screenshop > <http://jerome.jouvie.free.fr/jogl-rc8-error.png> during the freeze). > rc6 and rc7 also show this problem. > > I'm running Windows 7 64 bit with a NVidia GTX 260 with drivers up to date > (296.10). > > Using GLCanvas instead of NEWT solve the problem, ie everything start properly > and no freeze, but would be better if I could fix the exception with newt. > Is someone have seen this problem or have a suggestion to fix it ? > I am afraid we have a NEWT regression in this case and we shall fix it of course. Can you provide a test case or at least a very detailed procedure using the existing tests/demos to reproduce the freeze/starvation ? In the meantime .. I guess you are using your own RenderLoop for periodic rendering. You may like to register it as an GLAnimationControl via GLAutoDrawable: "public void setAnimator(GLAnimatorControl animatorControl)" This will remove GLAutoDrawable's (GLWindow ..) immediate render attempt (the display() call). This behavior allows fluent rendering in case an animation is being performed by a registered GLAnimatorControl. Even though the above will avoid the freeze and allows a more fluent animation, let's fix the root cause of the freeze :) ~Sven > Exception in thread "RenderLoop-0" java.lang.RuntimeException: Waited 5000ms for: <7ef3de76, 2b521f12>[count 1, qsz 0, owner <RenderLoop-0>] - <main-Display-Windows_nil-1-EDT-1> > at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:182) > at jogamp.opengl.GLContextImpl.lockConsiderFailFast(GLContextImpl.java:238) > at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:393) > at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:415) > at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:364) > at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:560) > at com.jogamp.newt.opengl.GLWindow$1.windowResized(GLWindow.java:91) > at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:2314) > at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:2257) > at jogamp.newt.WindowImpl.sizeChanged(WindowImpl.java:2401) > at jogamp.newt.driver.windows.WindowsWindow.reconfigureWindow0(Native Method) > at jogamp.newt.driver.windows.WindowsWindow.reconfigureWindowImpl(WindowsWindow.java:201) > at jogamp.newt.WindowImpl$SetSizeAction.run(WindowImpl.java:821) > at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:193) > at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:1578) > at jogamp.newt.WindowImpl.setSize(WindowImpl.java:844) > at com.jogamp.newt.opengl.GLWindow.setSize(GLWindow.java:340) > at jogamp.newt.awt.event.AWTParentWindowAdapter$1.run(AWTParentWindowAdapter.java:101) > at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:116) > at jogamp.newt.DefaultEDTUtil$EventDispatchThread.run(DefaultEDTUtil.java:295) > java.lang.RuntimeException: Waited 5000ms for: <7ef3de76, 3c925617>[count 1, qsz 0, owner <main-Display-Windows_nil-1-EDT-1>] - <RenderLoop-0> > at jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock(RecursiveLockImpl01Unfairish.java:182) > at jogamp.newt.WindowImpl.lockSurface(WindowImpl.java:562) > at jogamp.opengl.GLDrawableImpl.lockSurface(GLDrawableImpl.java:195) > at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:397) > at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:415) > at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:364) > at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:560) > at jouvieje.scene.target.jogl2.NativeCanvas_jogl2.onDisplay(NativeCanvas_jogl2.java:121) > at jouvieje.opengl.RenderLoop$Loop.run(RenderLoop.java:62) > > Jérôme > > > If you reply to this email, your message will be added to the discussion below: > http://forum.jogamp.org/GLWindow-setSize-exception-upgrading-to-rc8-tp3966421.html > > To start a new topic under jogl, email [hidden email] > To unsubscribe from jogl, click here > < > NAML > <http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- health & wealth mailto:[hidden email] ; http://jausoft.com land : +49 (471) 4707742 ; fax : +49 (471) 4707741 Timezone CET: PST+9, EST+6, UTC+1 |
signature.asc (910 bytes)
Re: GLWindow.setSize exception upgrading to rc8
|
|
Re: GLWindow.setSize exception upgrading to rc8
Administrator
|
Re: GLWindow.setSize exception upgrading to rc8
|
|
Re: GLWindow.setSize exception upgrading to rc8
|
Administrator
|
In reply to this post by jouvieje
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 |
Re: GLWindow.setSize exception upgrading to rc8
|
Administrator
|
Re: GLWindow.setSize exception upgrading to rc8
|
|
Re: GLWindow.setSize exception upgrading to rc8
|
Administrator
|
Re: GLWindow.setSize exception upgrading to rc8
|
|
Re: GLWindow.setSize exception upgrading to rc8
|
|
Re: GLWindow.setSize exception upgrading to rc8
|
Administrator
|
| Free forum by Nabble | Edit this page |