home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.sgi.graphics
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
- From: randy@caesar.iaf.uiowa.edu (randy frank)
- Subject: A quick swapbuffers question...
- Message-ID: <1992Dec30.163152.22459@news.uiowa.edu>
- Sender: Randy Frank
- Date: Wed, 30 Dec 1992 16:31:52 GMT
- Distribution: usa
- Nntp-Posting-Host: caesar.iaf.uiowa.edu
- Organization: University of Iowa, Image Analysis Facility
- Keywords: swapbuffers
- Lines: 34
-
- Hello,
- A quick question about the behavior of the swapbuffers() call
- that just came up around here. Does swapbuffers() actually block the
- current process at the point where swapbuffers() is called in the
- code until the next screen refresh right after swapbuffers() is called,
- or is the process blocking deferred until the next GL call is made?
-
- In the specific case in question:
-
- /* draw the scene */
- (some GL graphics code)
- swapbuffers();
- /* do some more work */
- (some non-graphics code)
-
- In one application it appears that some of the non-graphics
- code may be getting executed when the swapbuffers() call should be
- blocking the process for the next screen refresh. Note: I cannot
- verify this problem completely, it just seems like this may be the
- case.
- Could the optimizer be reordering the code so the non-graphics code
- is executed before the swapbuffers() call?
- Does swapbuffers() not actually block until another GL call is made
- (thus the non-graphics code is executed before the process must block)?
-
- BTW: The machines in question are r3k Entry and Elan Indigos running
- 4.0.1 and 4.0.2 respectively.
-
- Thanks in advance,
- --
- rjf.
- Randy Frank, Engineer | (319) 335-6712
- University of Iowa, Image Analysis Facility | 73 EMRB
- randy@tessa.iaf.uiowa.edu | Iowa City, IA 52242
-