Stereo sync

[Mark Stadler]

In article <1990Dec3.181548.5300 at odin.corp.sgi.com> thant at horus.esd.sgi.com (Thant Tessman) writes:
>In article <17848 at thorin.cs.unc.edu>, certain at hatteras.cs.unc.edu writes:
>> I am try to get a stereo display program to work on an Iris.  The problem
>> that I am having is that to stereo plate flips between the left and right
>> eye at 60Hz, so I need to make sure that I am alternating eyes with each
>> buffer swap.  Unfortunately, swapbuffers() is non-blocking, so that if I
>> can actually draw faster than 120Hz, I get two updates per buffer swap,
>> which has the effect of always just showing one eye.  Is there a way to
>> make swapbuffers() to be blocking?  Is there a way to know when the screen
>> refresh happens?  What have other people done about this problem?  I have
>> just subscribed to this newsgroup, so I don't know if this problem has been
>> addressed previously.
>
>gsync() might be what you need, at least to block on a refresh.
>

it is true that swapbuffers() is non-blocking, but only until you attempt to
perform the next graphics operation.  if you issue a swapbuffer() command,
then you are free to go off and do some number crunching, or update internal
data structures etc... but once you attempt to do the next graphics command,
your process will block until the pending swapbuffer() completes.  if you
issue a swapbuffer() command and immediately follow it with any other
graphics command you will hang until the swapbuffer is complete.  i think
i'm getting repetetive.  anyway, i wish i could help explain what your problem
really is.  all i can say that it has nothing to do with non-blocking swapbuffer().

by the way, gsync() (in the near future) will also be non-blocking, so don't
count on it for absolute times.  it will block only block if you attempt to
do another graphics command before the next vertical retrace.

--
-- mds	[aka Mark D Stadler  mds at sgi.com  ...!uunet!sgi!mds  (415)335-1327]