Curtis L. Olson wrote:
Your patch helps, but typically the semantics of sleep() commands is they will sleep at least as long as the requested time (up to the kernel trap timing resolution) so I am still seeing dropped frames, although not nearly as bad. If the kernel timing resolution is different than the monitor refresh resolution with no convenient multiples (i.e. 60hz vs 100hz), it's always going to be imperfect.
Here is some additional data. I note the requested sleep time, then measure the actual sleep time. If the sleep time is greater thanTimes are in milleseconds ...
requested = 5 actual = 6.898 requested = 6 actual = 7.998 requested = 6 actual = 7.269 requested = 5 actual = 6.358 requested = 2 actual = 3.230 requested = 7 actual = 8.972
So it looks like at least on the linux kernel-2.6.x you can get pretty fine sleep resolution, but it's always a few milleseconds more than you asked for.
Usually the sleep overshoot is 1,2, or even 3 milleseconds, but I did some tracking and saw it as high as 17 milleseconds on occasion. Backing off and sleeping 1 ms less than the target helped, but you'd probably have to back off 2-3 for more consistant results, and at least 17ms for perfect results.
I don't think is possible to do accurate millesecond timing with a sleep command on consumer operating systems. You can get close, but not close enough, because if you drop even one frame a second, your eye can spot it and notice the animation jitter.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list Flightgearfirstname.lastname@example.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d