Re: screen refresh (vbl) synchronization behavior
- From: Michael I Gold <gold@xxxxxxxxxxxxxxxxxxx>
- Date: Tue, 20 Dec 2005 16:46:12 -0800
forkazoo wrote:
Just because the function has returned doesn't necessarily mean the swap has actually occurred. It may just be queued for the next retrace. If you are rendering so fast that you swap buffers more than once per frame, then the queue is already full, and the swap won't return until the queue is cleared by the end of the retrace.
Correct - even the Nth SwapBuffers of a given retrace could return immediately if the implementation is capable of queuing up an infinite number of frames. The fact that it blocks indicates that the implementation (wisely) doesn't wish to allow so many frames to be queued up, or simply that it lacks the memory to continue queuing.
In fact, there is a chance that any GL call (including something as seemingly mundane as glColor3f) can block if the internal buffers are full and it causes an implicit flush. This is implementation dependent, of course.
So, are you seeing tearing? If not, then everything is working as it should.
Word. .
- References:
- screen refresh (vbl) synchronization behavior
- From: aaronsg
- Re: screen refresh (vbl) synchronization behavior
- From: Michael I Gold
- Re: screen refresh (vbl) synchronization behavior
- From: fungus
- Re: screen refresh (vbl) synchronization behavior
- From: aaronsg@xxxxxxxxxxxxx
- Re: screen refresh (vbl) synchronization behavior
- From: Michael I Gold
- Re: screen refresh (vbl) synchronization behavior
- From: aaronsg@xxxxxxxxxxxxx
- Re: screen refresh (vbl) synchronization behavior
- From: forkazoo
- screen refresh (vbl) synchronization behavior
- Prev by Date: NURBS trimming problem
- Next by Date: Re: screen refresh (vbl) synchronization behavior
- Previous by thread: Re: screen refresh (vbl) synchronization behavior
- Next by thread: Re: screen refresh (vbl) synchronization behavior
- Index(es):
Relevant Pages
|