Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!ames!sgi!shinobu!odin!horus.esd.sgi.com!thant
From: thant@horus.esd.sgi.com (Thant Tessman)
Newsgroups: comp.sys.sgi
Subject: Re: Stereo sync (swapinterval)
Keywords: stereo
Message-ID: <1990Dec6.194603.7016@odin.corp.sgi.com>
Date: 6 Dec 90 19:46:03 GMT
References: <17848@thorin.cs.unc.edu> <1990Dec3.181548.5300@odin.corp.sgi.com> <mg.660259402@godzilla>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: thant@horus.esd.sgi.com (Thant Tessman)
Organization: Silicon Graphics Inc.
Lines: 26

In article <mg.660259402@godzilla>, mg@ (Mike Gigante) writes:
> 
[...]

> On gsync, I don't understand Thant Tessman's comment -- surely a swapbuffer
> doesn't happen until a vertical retrace anyhow -- so the gsync is redundant
> right?

The act of swapbuffering itself only happens on the vertical retraces.  The 
old swapbuffer used to freeze the program thread until that happened.  The 
new swapbuffer actually allows the program to continue as long as it doesn't
draw into the same context.  This allows swapbuffers to be ganged up.  A 
program that had three windows used to be limited to 3/60 of a second per 
update cycle assuming a swapbuffers was called for all three windows.  Now
the whole thing is only limited to 1/60 of a second if I understand it
correctly.

A call to 'gsync' would force the program to wait.  It isn't clear that 
this was the source of the original problem.  But I thought I'd mention
it.


> Mike
> mg@godzilla.cgl.rmit.oz.au

thant