jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock timeout exception

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock timeout exception

Vaxquis
I've a question/request for a feature concerning this class/method. Since timeouts (especially with default t=5000ms) are commonly generated, e.g. when starting OpenGL rendering ASAP after starting the app (or when resizing a Swing window, due to the sheer amount of redraws needed and when there's no setSize event filtering implemented), could you possibly do one or couple of the following:
a) change the type of exception cast on timeout from RuntimeException to something more unique and explicit, allowing catching this single exception and handling it in a proper way,
b) reduce the amount of exceptions cast - currently there are 2 exceptions on every timeout, one from jogamp.newt.DefaultEDTUtil$EventDispatchThread.run (uncatchable, since it happens in a NEWT EDT thread) and the other one in client code - frankly I think that one exception is enough, see below -
c) provide me with some clues for logical way of handling your RuntimeException-s - for me, there should be an option for quiet timeouts, resulting in a frameskip in laggy conditions (code below shows the general idea behind it),
d) give me some insight what was your intention when it came to desiging this general timeout concept.

proof of concept code:

    SC3D_animator.add( new SC_Timer.descriptor() {
      @Override
      public boolean timer_event() {
        if ( my_GLEL.is_disposed() ) {
          SC3D_animator.stop(); // schedule timer stop
          return false;
        }
        try {
          f_newt.display();
        } catch (Exception ex) {
          if ( ex.getStackTrace()[0].getClassName().equals( "jogamp.common.util.locks.RecursiveLockImpl01Unfairish" ) )
            global.debug_info( "frame timeout in drawing code" );
          else
            global.report_exception( ex );
        }
        if ( display_FPS )
          f_cp.setTitle( base_title + " - FPS: " + (float) ( (int) ( f_newt.getLastFPS() * 100 ) ) / 100 );
        return true;
      }

works as intended (frameskip on lag), but still floods the stderr with exception reports from EDT.

regards, Vax.
Reply | Threaded
Open this post in threaded view
|

Re: jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock timeout exception

Vaxquis
note: this is also a common problem for me, any ideas?

      javax.media.opengl.GLException: Error making context current: 0x0x20000, werr: 0, WindowsOnscreenWGLContext [OpenGL 3.3, options 0x103, 3.3 (Compatibility profile, arb, ES2 compatible, hardware) - 3.3.0, handle 0x20000, jogamp.opengl.gl4.GL4bcImpl@5697cf,
        Drawable: WindowsOnscreenWGLDrawable[Realized true,
        Factory   jogamp.opengl.windows.wgl.WindowsWGLDrawableFactory@1089735,
        handle    0x12011575,
        Window    jogamp.newt.driver.windows.WindowsWindow[Config WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0], idx 0], pfdID 7, 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[GL3bc/GL3bc.hw]],
        chosen    GLCaps[wgl vid 0x7 arb: on-scr, rgba 0x8/8/8/1, trans-rgba 0x0/0/0/0, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, dbl, mono  , hw, GLProfile[GL3bc/GL3bc.hw]]]
, NEWT-Screen[Windows_nil-10, idx 0, refCount 1, 1280x1024, DefaultGraphicsScreen[WindowsGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0], idx 0], NEWT-Display[Windows_nil-1, refCount 1, hasEDT true, edtRunning true, WindowsGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0]]]
, ParentWindow JAWT-Window[windowHandle 0x9f012e, surfaceHandle 0x0, bounds [ 0 / 0  794 x 575 ], insets [ l 0, r 0 - t 0, b 0 - 0x0], shallUseOffscreenLayer false, isOffscreenLayerSurface false, pos 0/0, size 794x575, 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 0x7 arb: on-scr, rgba 0x8/8/8/1, trans-rgba 0x0/0/0/0, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, dbl, mono  , hw, GLProfile[GL3bc/GL3bc.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[GL3bc/GL3bc.hw]],
        sun.awt.Win32GraphicsConfig@1e02ee9[dev=D3DGraphicsDevice[screen=0],pixfmt=7],
        encapsulated WindowsWGLGraphicsConfiguration[DefaultGraphicsScreen[WindowsGraphicsDevice[type Windows, connection decon, unitID 0, handle 0x0], idx 0], pfdID 7, 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[GL3bc/GL3bc.hw]],
        chosen    GLCaps[wgl vid 0x7 arb: on-scr, rgba 0x8/8/8/1, trans-rgba 0x0/0/0/0, accum-rgba 16/16/16/16, dp/st/ms: 24/0/0, dbl, mono  , hw, GLProfile[GL3bc/GL3bc.hw]]]],
        awtComponent com.jogamp.newt.awt.NewtCanvasAWT[canvas0,0,0,794x575],
        surfaceLock <ff33c6, a03094>[count 0, qsz 0, owner <NULL>]]
, ParentWindowHandle 0x9f012e (true)
, WindowHandle 0x4a00be
, SurfaceHandle 0x12011575 (lockedExt window false, surface false)
, Pos 0/0 (auto false), size 794x575
, Visible true, focus false
, Undecorated false (true)
, AlwaysOnTop false, Fullscreen false
, WrappedWindow null
, ChildWindows 0, SurfaceUpdatedListeners num 0 [], WindowListeners num 2 [com.jogamp.newt.opengl.GLWindow$1@d5533a, com.jogamp.newt.awt.NewtCanvasAWT$2@14b3266, ], MouseListeners num 1 [jogamp.newt.driver.windows.WindowsWindow$MouseTracker@1d9d590, ], KeyListeners num 1 [vax.sqvaardcraft.ui.sc3d.SC3D_test$model_GLEL$biped_cameraman@53fb88, ], surfaceLock <1a6af53, 408eb0>[count 1, qsz 0, owner <SC_Timer-1>], windowLock <57d55a, 78404e>[count 1, qsz 0, owner <SC_Timer-1>]]], lock <c5e60d, 8287e2>[count 1, qsz 0, owner <SC_Timer-1>]]
        jogamp.opengl.windows.wgl.WindowsWGLContext.makeCurrentImpl(WindowsWGLContext.java:368)
        at jogamp.opengl.GLContextImpl.makeCurrentWithinLock(GLContextImpl.java:557)
        at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:424)
        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 vax.sqvaardcraft.ui.sc3d.SC3D_test$2.timer_event(SC3D_test.java:611)
Reply | Threaded
Open this post in threaded view
|

Re: jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock timeout exception

Sven Gothel
Administrator
In reply to this post by Vaxquis
On 05/18/2012 12:53 AM, Vaxquis [via jogamp] wrote:
> I've a question/request for a feature concerning this class/method. Since
> timeouts (especially with default t=5000ms) are commonly generated, e.g. when
> starting OpenGL rendering ASAP after starting the app (or when resizing a
> Swing window, due to the sheer amount of redraws needed and when there's no
> setSize event filtering implemented),

We have to consider this a bug,
either in JOGL or while using JOGL.

Instead of going through your list of workarounds,
allow us to understand what causes the timeout.

Pls provide a _complete_ one-class example which reproduces
the behavior either here, or as a new bugreport (preferred).

Thank you.

~Sven

Reply | Threaded
Open this post in threaded view
|

Re: jogamp.common.util.locks.RecursiveLockImpl01Unfairish.lock timeout exception

Vaxquis
This post was updated on .
Didn't even consider this a bug, but now it seems clear to me that nr 1 was the duplicate of http://forum.jogamp.org/GLWindow-setSize-exception-upgrading-to-rc8-td3966421.html - I'm going to try the lastest build as soon as it goes out, it'll possibly straighten everything up.

As for the second case, "Error making context current", I've been unable to reproduce it on a regular basis, but it happens from time to time when Alt-Tabbing (i.e. switching to/from graphical context of the GL frame). Happened to anyone else?