FPSAnimator with nanoSeconds and variable framerate

hello,

the FPSAnimator provided by jogl is pretty cool, although there are two points i would like to improve.

  1. it is not possible to change the target-fps at runtime. (this is very useful for debugging)

  2. it uses java’s TimerTask and Timer which rely on milliSecond accuracy. it would be more precise if it would do nanoSecond accuracy.

now only i dont know how i can achieve this. should i just call System.nanoTime in a loop before advancing to the next frame?

i would be very grateful if you could share your ideas on this topic! thanks!

[quote]should i just call System.nanoTime in a loop before advancing to the next frame
[/quote]
The problem with that is that you’ll be wasting the CPU cycles for no good result. If you need that high resolution, you typically just want to run as fast as possible for the rendering loop. If you’re trying to keep your physics step size constant, then you can instead step physics a variable number of times per frame – see the canonical game loop.

yeah, i was trying to change the fps value on runtime, but it seems impossible, because fps value is determined during creation of fpsanimator, so the only idea i have is to delete fpsanimator, and create it again, but with a new fps value. sounds hard :wink:

thanks for your replies:

jwatte: no i dont want as fast as possible. infact in some reasons i want the update to drop down to 1fps. for example when another swing component is in the foreground, then the glcanvas does not need to be redrawn so often which would waste CPU time.

barret: yeah the current fpsanimator doesn support this, thats why i want to roll my own, but so far i dont know how to start. especially how to do the measuring if a certain amount of time has past, which would call the next frame.

If you just want to give up some time to other threads, you can call Thread.yield() in the main loop. If you want to give up a lot of time, you can call Thread.sleep(100) in the main loop. Spinning on nanoTime() is a bad idea, because you will waste CPU cycles doing exactly nothing. You might as well run as fast as possible when you want the higher frame rate, and tie the frame rate to the vertical retrace interrupt. When in the background, add the Thread.sleep(100) to be nice.

If you come up with improvements you’re happy with please file an RFE with the JOGL Issue Tracker and contribute your changes so the rest of the community can benefit.

jwatte, thanks, but what i want to achieve is a constant and exact framerate. like for example 25fps for video capturing. just sleeping for 100milis would give different framerates on different gpus.

ken, yes i will share my code, once it is stable enough.

You could possibly combine both methods. Use Thread.sleep(x) as long as there is enough time left and do a accurate nanoTime-checking loop with Thread.yield() (or Thread.sleep(1) as I read somewhere is also safe) for the “last 10%” accuracy.