Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!att!rutgers!mcnc!thorin!aesop!certain From: certain@aesop.cs.unc.edu (Andrew Certain) Newsgroups: comp.sys.sgi Subject: Re: Stereo sync (swapinterval) Keywords: stereo Message-ID: <17956@thorin.cs.unc.edu> Date: 4 Dec 90 22:50:06 GMT References: <17848@thorin.cs.unc.edu> <1990Dec3.181548.5300@odin.corp.sgi.com> Sender: news@thorin.cs.unc.edu Reply-To: certain@aesop.cs.unc.edu (Andrew Certain) Organization: University Of North Carolina, Chapel Hill Lines: 22 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. I can't use swapinterval because the plate we have switchs at 60Hz on its slowest setting. I guess we're going to have to go to a different stereo system like one with active glasses, since, no matter how simple the scene is that you're drawing, it is always possible that somebody will grab the processor for long enough to cause a left-right switch. Do people have recommendations on stereo systems? What about StereoView? On a slightly different note, I called m_set_procs to set the number of procedures on an m_fork to three and ran my program and was interested to see that, using gr_osview, all four processors we being used to a non-negligible(sp?) extent? Why does this happen? I think the same thing happens if I set it to two.... Andrew Certain certain@cs.unc.edu