Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!ucivax!orion.oac.uci.edu!ucsd!ames!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: Stereo sync (swapinterval)
Keywords: stereo
Message-ID: <77521@sgi.sgi.com>
Date: 8 Dec 90 04:10:31 GMT
References: <17848@thorin.cs.unc.edu> <1990Dec3.181548.5300@odin.corp.sgi.com> <17956@thorin.cs.unc.edu>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 17

In article <17956@thorin.cs.unc.edu>, certain@aesop.cs.unc.edu (Andrew Certain) writes:
> I admit it:  I was wrong.  My problem was more complex.  I have
> realized that swapbuffers indeed does block once you try to do a
> graphics call.  I have discovered that my problem was that although
> usually my program could draw the scene in 1/60th of a second,
> sometimes it wouldn't, and the eye would switch....

Could you use gettimeofday(2) or (better to avoid adjtime(2) effects)
times(2) to read the system clock, divide the resulting timestamp by a
number related to 1/60th sec, and depending on the remainder, use sginap(2)
or select(2) to delay a little to get back into sync?  Or maybe just do an
extra swapbuffer to delay?  Or instead of delaying, skip forward to the
correct frame?  If the cause is infrequent enough to make the resulting
artifacts unobjectionable?


Vernon Schryver,   vjs@sgi.com