Xojo Conferences
XDCMay2019MiamiUSA

OpenGL VSYNC screen synchronization (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Find app by creator and open an http address
Next thread: [OT] VM conversion WAS: Use of Parallels


Reading *CSV Files versus *.Txt Files   -   Claude Stone
  OpenGL VSYNC screen synchronization   -   Michael Diehr
   Re: OpenGL VSYNC screen synchronization   -   fargo rpgportland.com
   Re: OpenGL VSYNC screen synchronization   -   John Balestrieri

OpenGL VSYNC screen synchronization
Date: 27.01.09 21:17 (Tue, 27 Jan 2009 12:17:27 -0800)
From: Michael Diehr
I'm trying to accomplish fast & smooth OpenGL animations using the
OpenGL Declare library in REALbasic. I have a question about
threads, timers & animation.

In AGL, if you set AGL_SWAP_INTERVAL to 1, this tells the system that
all calls to AglSwapBuffers are to syncrhonize with the screen
refresh. This has a big advantage, in that it guarantees that the
content will be be updated to the screen only between screen
refreshes, which avoids "tearing" and other glitches.

However, this also means that any call to aglSwapBuffers will block
until the next VSYNC happens.

I'm running my openGL animations from a thread that sleeps between
calls, attempting to wake up every 16.67 msec, e.g.

Thread.Run
loop
elapsed =(microseconds-lastRenderTime)/1000
RenderScreen (does rendering and calls aglSwapBuffers)
me.sleep(min(0,16.67 - elapsed))
lastRenderTimer = microseconds
until false

The problem I see is that with complex animations, the frame rate
seems to switch between 60 and 30fps.

I suspect the problem is that if I call aglSwapBuffers just a
millisecond too late, then it has to wait until the next VSYNC, which
could be up to 16.67msec -- time which is basically just wasted time,
time I could have spent getting the next frame ready to render.

Any ideas about this? It almost seems like I should have two threads,
one which is rendering the next frame, and another which does the
actual call to aglSwapBuffers.

That way if the aglSwapBuffers thread blocks, the rendering thread can
keep preparing the next frame of animation?

Anyone else solved this elegantly?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: OpenGL VSYNC screen synchronization
Date: 28.01.09 02:51 (Tue, 27 Jan 2009 19:51:19 -0600 (CST))
From: fargo rpgportland.com
> I'm trying to accomplish fast & smooth OpenGL animations using the
> OpenGL Declare library in REALbasic. I have a question about
> threads, timers & animation.
>
> In AGL, if you set AGL_SWAP_INTERVAL to 1, this tells the system that
> all calls to AglSwapBuffers are to syncrhonize with the screen
> refresh. This has a big advantage, in that it guarantees that the
> content will be be updated to the screen only between screen
> refreshes, which avoids "tearing" and other glitches.
>
> However, this also means that any call to aglSwapBuffers will block
> until the next VSYNC happens.
>
> I'm running my openGL animations from a thread that sleeps between
> calls, attempting to wake up every 16.67 msec, e.g.
>
> Thread.Run
> loop
> elapsed =(microseconds-lastRenderTime)/1000
> RenderScreen (does rendering and calls aglSwapBuffers)
> me.sleep(min(0,16.67 - elapsed))
> lastRenderTimer = microseconds
> until false
>
> The problem I see is that with complex animations, the frame rate
> seems to switch between 60 and 30fps.
>
> I suspect the problem is that if I call aglSwapBuffers just a
> millisecond too late, then it has to wait until the next VSYNC, which
> could be up to 16.67msec -- time which is basically just wasted time,
> time I could have spent getting the next frame ready to render.
>
> Any ideas about this? It almost seems like I should have two threads,
> one which is rendering the next frame, and another which does the
> actual call to aglSwapBuffers.
>
> That way if the aglSwapBuffers thread blocks, the rendering thread can
> keep preparing the next frame of animation?
>
> Anyone else solved this elegantly?

I'm afraid I've never done anything elegantly. Really, I have no
experience with this, but why not just keep your thread running instead of
sleeping, and have it check the time resolution to determine a step? I
would think that would be more accurate timing. Anything is going to be
fallible at such a fine resolution, but every bit helps I'd guess.
Certainly couldn't hurt to try two threads. Is that going to be an
involved pain in the butt to try?

Best of luck,
Fargo

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: OpenGL VSYNC screen synchronization
Date: 28.01.09 03:41 (Tue, 27 Jan 2009 21:41:35 -0500)
From: John Balestrieri
IIRC, when you VSync, the frame rate will be a multiple of display
refresh rate. I don't think you should try to precisely time your
thread; you're not going to get the timing right. Just run the thread
faster than the frame rate than you have to either "waste" the time
rendering extra frames or skip rendering until the next loop. I don't
think it's worth it to throw in a thread sleep call.

John

On Jan 27, 2009, at 3:17 PM, Michael Diehr wrote:

> The problem I see is that with complex animations, the frame rate
> seems to switch between 60 and 30fps.
>
> I suspect the problem is that if I call aglSwapBuffers just a
> millisecond too late, then it has to wait until the next VSYNC,
> which could be up to 16.67msec -- time which is basically just
> wasted time, time I could have spent getting the next frame ready to
> render.
>
> Any ideas about this? It almost seems like I should have two
> threads, one which is rendering the next frame, and another which
> does the actual call to aglSwapBuffers.
>
> That way if the aglSwapBuffers thread blocks, the rendering thread
> can keep preparing the next frame of animation?
>
> Anyone else solved this elegantly?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>