Curtis L. Olson wrote: > Frederic Bouvier wrote: > > There is the property /sim/frame-rate-throttle-hz that could be > > used to limit the framerate but the source should be modified > > to call a system sleep method ( with a fine resolution, for > > example pthread_cond_timedwait ) instead of looping wildly. > > I know this is hard to do with standard system level calls. For > instance setitimer() in unix allows you to specify a very fine > resolution sleep/wakeup time. However, the OS only checks the > thread during a kernel interrupt which happens at 100hz. So you > can only get divisers of 100hz resolution with this approach.
Indeed. For what it's worth, almost all full screen 3D apps end up spinning on the CPU, for exactly this reason. Trying to sleep for tiny amounts of time really isn't doable in a portable way. Under linux, the real time clock device can be programmed to provide an I/O wakeup to a process at fine intervale (and because it is I/O bound, it is at high priority and generally gets the CPU immediately). But that's not even portable to other Unix kernels, much less windows. Really, the best thing you can do is to turn on sync-to-vblank in the OpenGL driver. This will throttle the process* to the monitor refresh rate, at least. Andy * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
