On mac os x, there's a way to pass the system a function pointer that is triggered at an ideal time to start your drawing code. These are the CVDisplayLink tools.

I'd like to understand how to do something analogous on windows. The ideal solution would:

  • Call a function I specify after the previous draw loop's data becomes visible on the monitor.
  • Avoid screen tearing.
  • Minimize overhead such as #buffers. For example, avoid triple buffering, and possibly even avoiding double buffering if that is possible.

My current setup is to execute a busy loop that constantly calls PeekMessage and starts a draw loop cycle every time there's no message. This is likely to result in more than 60 draw cycles per second, which is wasting CPU effort and results in calculated frames that are never displayed.

The best answer is one that allows me to do this without a third-party library (OpenGL and Win32 are definitely ok!); but it's still useful to know of open source libraries that solve this problem since I can then dive into the code myself.

Related notes: I've seen this stackoverflow page on OpenGL vsync and the the wglSwapIntervalEXT() function. I don't think these comletely solve my problem since the wglSwapIntervalEXT function only delays buffer swaps, and waiting for glFinish ties up my event loop. I've also heard that it's bad practice to call glFinish, and I don't know how it interacts with any buffers and vsync work windows is already doing for me. Maybe they are part of a full solution that I don't know of yet.

  • \$\begingroup\$ VSYNC will prevent you from drawing at ridiculously high frame rates. That is one of its only uses on a compositing window manager, because they can prevent tearing without VSYNC by asynchronously presenting its own front-buffer using the last complete copy of your application's front-buffer. The swap interval doesn't only delay buffer swaps, it jams up the render pipeline if all back-buffers (e.g. 1 if double-buffered, 2 if tripple-) are full of data waiting to be swapped to the front. This will fill up the command queue and eventually your program will block on a GL call. \$\endgroup\$ Commented May 2, 2014 at 1:53
  • \$\begingroup\$ See another answer I wrote for more details. \$\endgroup\$ Commented May 2, 2014 at 1:54
  • \$\begingroup\$ What about GetMessage()? Unlike PeekMessage(), it will block until a window event occurs. Also, you can easily limit the frame-rate of your application with a simple timer. \$\endgroup\$
    – glampert
    Commented May 2, 2014 at 3:04


You must log in to answer this question.

Browse other questions tagged .