Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!uakari.primate.wisc.edu!ames!sgi!shinobu!odin!bam From: bam@sgi.com (Brian McClendon) Newsgroups: comp.sys.sgi Subject: Re: Stereo sync (swapinterval) Keywords: stereo Message-ID: <1990Dec6.204558.7954@odin.corp.sgi.com> Date: 6 Dec 90 20:45:58 GMT References: <1990Dec3.181548.5300@odin.corp.sgi.com> <1990Dec6.194603.7016@odin.corp.sgi.com> Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 29 In article <1990Dec6.194603.7016@odin.corp.sgi.com> thant@horus.esd.sgi.com (Thant Tessman) writes: > >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. > > >thant On the VGX, 'gsync' acts just like swapbuffers(), only hanging the program when it tries to access gfx in the same window. This seems to do everything we could imagine gsync used for, but is slightly different from what might be expected. Any comments on how you _want_ it to work? -- ---------------------------------------------------------------------------- Brian McClendon bam@rudedog.SGI.COM ...!uunet!sgi!rudedog!bam 415-335-1110 ** Legalize drugs! ** ** RU486 ** ----------------------------------------------------------------------------