Curtis L. Olson wrote:

Frederic,

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.

Regards,

Curt.

--
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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to