Xojo Conferences
| XDC | May | 2019 | Miami | USA |
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
| 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> |