FPS counting; several windows.

Richard Rauch — Wed, 30 Mar 2005 05:18:19 -0000

Currently, the GLUT_FPS environment variable causes
OpenGLEAN to compute frames-per-second based on the
total number of redisplay events your application
handles---for all of your windows. This can render it
fairly meaningless.

Nigel Stewart thinks that this is a priority 7 issue
for OpenGLUT.

After posting the initial RFE for OpenGLUT, I am less
and less convinced that this is desirable, but I post
it here for rumination.

The advantage: It would be nice to know the current
frame rate in a more meaningful sense.

The disadvantages: GLUT_FPS only provides information
on {stdout} or {stderr}. To output info about every
window's FPS would spam the output. We could, of
course, add a glutGet(GLUT_WINDOW_FPS) or a
glutGet(GLUT_WINDOW_FRAMES) to ask how well a particular
window is doing. But the client can do their own fps
computations...

Especially if we can get a more accurate timer than
1ms (or sometimes 10ms, on WIN32?), it would be very
nice to start a window's FPS at 0, and then everytime
the window is about to be updated:

* Get the start time.
* Call the client redisplay callback.
* Get the finish time.
* total_time = finish - start;
* window->fps += 1/(total_time * timer_granularity);
* window->fps /= 2;

Whether or not GLUT_FPS should be aware of this, though,
I am not sure. GLUT_FPS is a fairly crude tool...

Now, seen as a glutGet()able value, I've talked myself
back into thinking that this is a feasible thing.
Maybe I'll do an API proposal...

Recent changes to 7: FPS counting; several windows.

FPS counting; several windows.