Quoting "Curtis L. Olson" : > Time out here! > > There are two reasons two throttle frame rate. > > 1. Conserve CPU time and leave more cpu time for other tasks. Using > sleep() calls you can put FG asleep for a short time if it gets done > drawing a frame early, leaving those cycles for other tasks. > > 2. Accurately control frame rate. Here you want to run at a fixed > precise frame rate to achieve smooth, jitter free rendering. For > instance, if you can't quite sustain 60hz consistanty, you might want to > throttle back to 30hz. > > The problem is that this new patch throws away the second reason in > favor of the first. When I throttle to 20hz, I get 19hz. When I > throttle to 30hz I get, ohh ... 28 or 29 depending. Putting the > application to sleep does terrible things to timing accuracy, because > typically the application can only wake up during a kernel trap, and if > you miss the vertical refresh by even 1 millesecond, you drop a frame > and get animation jitters. > > Maybe we need to figure out how to satisfy both needs, but we can't just > blindly dispense with reason #2 when a new need comes along. > > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation.
Maybe it is doable to sleep for a millisecond less than computed and achieve the targeted framerate with the loop. -Fred _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
