As my OpenGL application runs on kiosks, it’s monitored by a watchdog service, which among other things keeps the monitor suspended with PostMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, 2).
When the OpenGL application has fully started and is running, it signals so to the service, which powers up the monitor with PostMessage(HWND_BROADCAST, WM_SYSCOMMAND, SC_MONITORPOWER, -1).
I noticed that vsync doesn’t work if the OpenGL application starts up while the monitor is powered down, even though I call wglSwapIntervalEXT(1) during its startup. I can understand that there is probably no vsync signal coming from the monitor, but that only explains why there would be no vsync while the monitor is powered down, and doesn’t explain why blocking on swap buffers wouldn’t immediately come on when the monitor is powered u,p given I’ve set the swap interval to 1 previously. As it is, I have to keep track of this and call wglSwapIntervalEXT(1) after the monitor is up. Sounds like a driver or Windows bug to me, and it’s still a problem with the newest NVIDIA drivers and Windows 7 as well as 8.1, on GTX680 and 780 cards (these have been my test systems). Worse, the workaround of calling wglSwapIntervalEXT(1) after the monitor has powered up is itself problematic, as I have no robust way of knowing when it is, in fact, on–I don’t know how to ask Windows whether the monitor has powered up and is sending a vsync. Right now I’ve simply added a two second delay after the SC_MONITORPOWER wake up message before calling wglSwapIntervalEXT(1).
I have NVIDIA, with the driver’s vsync setting “Use the 3D application setting”. Please don’t suggest forcing vsync on in the driver–I do my own adaptive vsync by toggling wglSwapIntervalEXT 0/1 as needed based on framerate statistics.