Crash with Animator class

Hello

I'm write a little application that copies a sprite from a map from GPU-memory in a png file.
Sometimes if the sprite has the size from the map, e.g. 1000x663
i a got this Exception from jogl:

finishLifecycleAction(com.jogamp.opengl.util.FPSAnimator$3): ++++++ timeout reached ++++++ main-Display-.windows_nil-1-EDT-1
finishLifecycleAction(com.jogamp.opengl.util.FPSAnimator$3): OK false- pollPeriod 8, blocking true -> res false, waited 1000/1000 - main-Display-.windows_nil-1-EDT-1
 - com.jogamp.opengl.util.FPSAnimator[started true, animating true, paused false, drawable 1, totals[dt 0, frames 0, fps 0.0], modeBits 1, init'ed true, animThread Thread[main-FPSAWTAnimator#00-Timer0,5,main], exclCtxThread false(null)]
    [2]: com.jogamp.opengl.util.AnimatorBase.finishLifecycleAction(AnimatorBase.java:633)
    [3]: com.jogamp.opengl.util.FPSAnimator.stop(FPSAnimator.java:326)
    [4]: com.lib.jengine.utils.ReadingFromScreenTexture.display(ReadingFromScreenTexture.java:163)
    [5]: jogamp.opengl.GLDrawableHelper.displayImpl(GLDrawableHelper.java:692)
    [6]: jogamp.opengl.GLDrawableHelper.display(GLDrawableHelper.java:674)
    [7]: jogamp.opengl.GLAutoDrawableBase$2.run(GLAutoDrawableBase.java:443)
    [8]: jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1293)
    [9]: jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1147)
    [10]: com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:759)
    [11]: jogamp.opengl.GLAutoDrawableBase.defaultWindowRepaintOp(GLAutoDrawableBase.java:215)
    [12]: com.jogamp.newt.opengl.GLWindow.access$100(GLWindow.java:119)
    [13]: com.jogamp.newt.opengl.GLWindow$2.windowRepaint(GLWindow.java:136)
    [14]: jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:4401)
    [15]: jogamp.newt.WindowImpl.consumeEvent(WindowImpl.java:3372)
    [16]: jogamp.newt.WindowImpl.doEvent(WindowImpl.java:3318)
    [17]: jogamp.newt.WindowImpl.windowRepaint(WindowImpl.java:4715)
    [18]: jogamp.newt.driver.windows.DisplayDriver.DispatchMessages0(Native Method)
    [19]: jogamp.newt.driver.windows.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:124)
    [20]: jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:753)
    [21]: jogamp.newt.DisplayImpl$7.run(DisplayImpl.java:672)
    [22]: jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:347)

Synchronising problems or DMA problems from framebuffer copiing a big map?
Or must i set my jogl FPSAnimator in another way?

Normaly,in a standalone application for copiing only a sprite its not a problem,
the next try then does the job, but using this (e.g. make a screenshot)
in another running environment, can be a problem.  

Hi

Do you really need a FPSAnimator? Would a plain Animator be enough for this purpose?

With Animator the problem occurs constant.  

The FPS should be constant.
The normal animator runs so fast as possible?
Different graphicscard displays also with a different speed.
For testing and some time calculations its not so good  
Otherwise i must self calculate the FPS rate.

I stop the Animator class in the display method from the GLEventListener class,
because grapping the texture from the graphiccards memory,
i can do in the init method from that class.
   
It can be, that display method is called before
the init method has read the complete texture in the framebuffer?

With Animator

If you use setSwapInterval 1 then you get one update per frame
typically 60 frames / second

setSwapInterval 2 == every second frame typically 30 frames / second

setSwapInterval 0 == run as fast as possible ( not recommended)


@Override
public void init(GLAutoDrawable drawable) {

drawable.getGL().setSwapInterval(1)


2017-03-08 15:53 GMT+01:00 adi [via jogamp] <
ml-node+s762907n4037751h44@n3.nabble.com>:

> The FPS should be constant.
> The normal animator runs so fast as possible?
> Different graphicscard displays also with a different speed.
> For testing and some time calculations its not so good
> Otherwise i must self calculate the FPS rate.
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.jogamp.org/Crash-with-Animator-class-tp4037748p4037751.html
> To start a new topic under jogl, email ml-node+s762907n782158h61@n3.
> nabble.com
> To unsubscribe from jogamp, click here
> <http://forum.jogamp.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=762907&code=eGVyeGVzQGd1ZGlubmEuY29tfDc2MjkwN3wtNTE5NjUwMzEw>
> .
> 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>
>

60 Frames is to low. The most eyes need 72 frames per second
to registrate no flickering.
(Most people have no monitor and graphicscard with adaptive sync,
so that fps must controlled by software.)

Actually, if the hardware was perfectly accurate, only 21 frames per second would be enough for human eyes (based on the knowledge on persistence of vision).

to summarise: the monitor refresh rate is what limits you how many real frames per second you can display

We recommend using the Animator class and using gl.setSwapInterval(1) to render one frame for each monitor update.

The JogAmp API MonitorMode api allow you to switch to a monitor mode with the desired refreshrate you want. Example on how to use MonitorMode is found in the javadoc and in the jogl junit tests:
https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/newt/MonitorMode.html

When working with high FPS having a good high resolution timer is essential for smooth animations:
// use JogAmp high resolution timer for smooth animations!
com.jogamp.common.os.Platform.currentTimeMicros();

example: on my linux system i can list what refresh rates my monitor support using xrandr or the JogAmp MonitorMode API. If i Switch to 1280x1024 then my monitor is actually able to run at 75.02 real FPS and by using the Animator class i can render one frame each monitor update! If i use 1920x108 i can only get 60 real FPS.

If I buy a better monitor then I can use  240Hz modes that will give me more real FPS.
update: there are some extreme monitors able to do 480Hz and 960Hz... crazy times :)

   1920x1080     60.00*+  59.99    59.94    50.00    60.05    60.00    50.04  
   1680x1050     59.95  
   1600x1200     60.00  
   1440x900      59.89  
   1366x768      59.79  
   1280x1024     75.02    60.02  
   1280x960      60.00  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  

I will test it with gl.setSwapInterval(1).
At 1920x1080 i have 144 HZ.
But for other monitors i test always with 72 HZ fixed rate.
 (In my version jogl version 2.3.2 is no com.jogamp.common......)
 

com.jogamp.common is in GlueGen:
http://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/com/jogamp/common/os/Platform.html

Thanks.

With PBO's i could make asnychrones reading and so
the problem vanishes. It seems, that the Animator class
gets problems with synchronous data transfer, if the blocking
time from readPixel is to large, he cant't do his job correct i think.