You can measure your frame time at the beginning of your display() method and Thread.sleep() or Object.wait() for the remainder of say 20 ms.

Someone was posting on the gl4java mailing list about this recently and it probably should be added to the Animator class.

However think about why you want to do this -- is it to keep CPU usage down? Or to avoid looking at wall clock time in your animation loop? If it's the latter then you should probably consider adding a notion of elapsed time to your animations, because doing so will provide framerate independence.

If you look at the code for the Animator class, the main thread runs in a tight loop with no sleep() or yield().  This is not very swing friendly, and I noticed that in some of my practice programs, the gui interaction was very jerky.

Please put in FPS functionality, so swing events can be handled in a timely fashion and so we can drive other functions like AI, etc. within controlled timeslices.

I ended up cut and pasting the Animator class to my own package and adding a sleep(33) within the run loop. Oh by the way, is the GLCanvas.willSetRenderingThread() supposed to be protected? or was the "public" modifier left off by accident?  Can it be public so we can use the NVidia bug fix from classes we make from scratch?

If you don't want to mess with the Animator class, I bet you can just put a sleep() line at the end of your display() code.  I don't bother with calculating the exact time delta, right now, because my notebook fps tops at 30fps, and I'm on winXP so the timer is not accurate anyways.

After the sleep fix, my programs run just like it did in GL4Java, except for any demo with teapots...Can anyone port the glutTeapot() soon?  I really like the teapot!

I think that a Fps-lock like we know and love it from Gl4java via myGLcanvas.setAnimateFps(50) is a must-have. (This is no complain, because Jogl is very young, it's just a suggestion. :-)

There are many cases where the animation of the GLcanvas suffices with 50 fps (or any other value).

In the model-view-controller (MVC) system of a few full-price games I know it's usual to limit the FPS of the view-part to a fixed value (changable via option maybe) so that the fixed timer based model-part driving the simulation got it's CPU time in a reliable way.