FPSAnimator etc. . . controlling CPU use

OpenGL Development JOGL Development
#1

Why do people use these classes when they could do the following in their display loop:

int fps = 50;
long timeperframe = 1000000000/fps;

time = System.nanoTime();
DO STUFF
time = System.nanoTime() - time;
//time is currently the elapsed time used

time -= timeperframe;
//time is now the extra time that is not used

if(time<0) {time = 0;}

try { Thread.sleep(time) }
catch (Exception e) { //do something sensible
}

Is this a bad method? If so why? I know before java 1.5 was available there wasn’t access to the most accurate available system timer, but now there is whats wrong with using it?

#2

I’d like to know the answer to this, too. It seems like less work than setting up a timer like what I’ve seen in the FPSAnimator class.

I’d also like to know whether or not it’s better to use sleep() or wait().

#3

I think you made a little mistake in your method

Actually time would now be not the extra time available, but the time that your display used additionally of its alloted 1/50th of a second.
So basically when your display time is superior to 1/50th of a second you make it worse by letting the thread sleep by this same margin.So you’ll never reach the desired 50fps.
So, Instead of

it should be

#4

On windows 98, Thread.sleep() is poorly accurate (minimum sleep is 50 ms, so Thread.sleep(1, 2, 3…) == Thread.sleep(50) ).
Better on later versions.

So use this method if you don’t target W98 systems.

Lilian

#5

[quote]On windows 98, Thread.sleep() is poorly accurate (minimum sleep is 50 ms, so Thread.sleep(1, 2, 3…) == Thread.sleep(50) ).
Better on later versions.

So use this method if you don’t target W98 systems.

Lilian
[/quote]
Is there a good alternative to thread.sleep() then?

#6

[quote]Is there a good alternative to thread.sleep() then?
[/quote]
A while loop with a Thread.yield() inside it.

#7

as a jogl noob im interested in an answer too. but i didnt see one …

#8

I wrote that class when I was making a bunch of nehe jogl ports to get a more stable framerate than what the standard Animator provided. That was about a year or more ago IIRC. Jdk 1.5 was definitely not available yet. As someone already said pre jdk 1.5 there was no way to accurately measure rendering time without using external timer libraries, which was something I wanted to avoid.
To answer the question at hand, no I don’t think the timer is the absolute best way to implement constant FPS. It was just the first solution that came to mind back then :slight_smile: It worked accurately enough for the purpose of those nehe demos, so I just kept it that way.
On the sleep/wait question. The two do different things. sleep() simply suspends the thread for some time. The only way to jump out of a sleep is to either wait for the sleep time to pass or to interrupt the thread that’s sleeping. wait() waits on an object’s monitor. You can jump out of a wait by calling notify()/notifyAll() on the object.
The yield() in a loop solution is IMO suboptimal. It will only have the desired effect if all threads have equal priority. This is probably the case in most games, but not so in general.

#9

I’m having a similar problem. JOGL starves other applications.
I’m using a client-server setup with proxy objects that use dead reckoning to update themselves.
I don’t care much about constant FPS but the JOGL Animator starves my server application
when I test everything on the same machine.

Is there any way to ensure that another application will not be starved?