#7 FPS counting; several windows.

[Richard Rauch]

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...

[Richard Rauch]

Logged In: YES
user_id=854844

As a glutGet()able value, though, we no longer need to think
about the GLUT_FPS variable. Accumulating per-window stats
is cheap enough that we can always accumulate it. The
GLUT_FPS concept of printing a frame rate perhaps should be
discouraged; useful as it is for special cases (and hence it
shouldn't be removed), I don't see any way to handle multiple
windows with it in a nice way.

So, we're really looking at two separate things: Statistics
accumulation, and printing statistics on the console. The
former can be improved (albeit in no way that the client
can't do as well for themselves...), and the latter is useful
enough to be retained but can't be much improved that I can
see.

After this ramble, I'm inclined not to make any changes to
OpenGLEAN in this regard.