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.


* 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

Reply via email to