🚀 go-pugleaf

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