On 08.02.2012 17:48, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>>> It was originally meant to run on the idle loop, and with this WIN32
>>> that runs about 3,000 FPS.
>>
>> I don't get more than approx. 60 (!) FPS on my Win7 box (4 cores, with
>> the CPU at a minimum load)
>
> Hmm, that may be a GL driver issue - on these boxes here, the (WIN32) GL
> driver offers an option to synch to the monitor refresh, or not.
> With the synch enabled (which IIRC may be the default) I get a solid 60
> FPS in the "idle loop" case, which matches the monitor setting of 60Hz.
> With the synch disabled, on this box I see something like 2759 FPS or
> so, though with some variation...
Yep, that was it. Now I see 64.2 FPS (more than 60, but still much less
than requested at any rate with timers), but more than 6.100 FPS with
the idle loop.
>>> I've added an fl_timer aiming for 100 FPS, and on this box I get a
>>> rock-solid 64 FPS... Hmm, 64 != 100, so that's odd.
>>
>> Same value: ~60 FPS
>>
>>> I wonder if I'm hitting some issue with the resolution of the WIN32
>>> timers or something, as the FPS I get is *exactly* 64, even though
>> the
>>> idle-loop version runs much, much faster...
>>
>> Running at /desired/ frame rate 30 gives me 21.4 FPS. Strange.
>
> Hmm, OK, I just tried setting desired to 30, and got exactly 21.4 too.
> That is odd, but since we see it on two distinct machines, I wonder if
> there is some interaction with the way WIN32 handles it's timers, or
> something?
Looks so, maybe. I see different distinct FPS values for other requested
frame rates, such as 21.4 (requested: 30), 32.1 (34, 40, 58), but never
more than ~64. To check the timer issue, we should rule out the GL part,
though, but that'd be another test...
>> The same program, compiled in a Linux VM on the *same* Win7 box gives
>> me up to 516 FPS with idle loop and ~450 FPS with timers.
>
> I guess the VM is is emulating GL, e.g. MESA or whatever, so that
> accounts for the low "idle" frame rate - but why is the "timed" version
> higher than desired?
>
>> I'm wondering what's going on...
>
> That does not sound like the timers "worked" at all on the linux test
> though, if it was running faster than desired.
No, it didn't, sorry for the confusion.
I tested with different desired rates, and the what I wrote were
the highest rates I could get. All rates were more or less equal
to the requested rate or a little lower, until you come to the
"saturation" point: if you request more than the system can handle,
then the real (measured) rate breaks down, but that's what I would
expect anyway (particularly because the measurement also works with
timers, and this may render the values useless).
BTW: I added a commandline arg for my tests (requested rate), and if
this was 1000 or higher, I switched to idle loop automatically. This
way you can test easily at different frame rates. I didn't test with
Greg's mods yet.
Here is an excerpt of what I changed (sorry, no diff available), in
case someone liked to try:
// in function init:
double opt_rate; // added
// later, in argument parsing code:
else if ( (opt_rate = atof(argv[i])) > 1 ) {
desired_frame_rate = opt_rate;
per_frame_time = 1.0 / desired_frame_rate;
}
// in main, after starting the measurement timer
printf("running at desired frame rate: %.0f FPS, using
",desired_frame_rate);
if (desired_frame_rate > 999) {
printf("Fl::add_idle()\n");
Fl::add_idle(idle_fl); // Takes the place of the glut idle loop
}
else {
printf("Fl::add_timeout() + Fl::repeat_timeout()\n");
Fl::add_timeout(per_frame_time, fixed_fps); // draw at desired FPS
}
fflush(stdout);
Note that this hack could probably be improved. Also, adding GUI
elements as Ian suggested looks like a good idea for the final test
program.
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
