vsync_test | completely stupid amount of man hours

vsync_test is a C library. vsync_test has no bugs, it has no vulnerabilities and it has low support. You can download it from GitHub.

OK I have spent a completely stupid amount of man hours making an extremely simple program -- drawing a single triangle that follows the mouse cursor with minimal input lag, and with vsync, perfectly smooth. I am confident I have found at least one pretty serious (at least in my opinion) bug in DWM (or two bugs that are somewhat connected -- I will be describing only one of them here). When you alt+tab out of a windowed application (there are possibly other triggers too), there's a chance that DWM (or something related to DWM) falls out of sync with either the presentation of the application's frames, or with the underlying hardware layer. It seems to be connected to the number of other windows that are open (speculation: it has to do with the time it takes to compose that alt+tab screen). On one of 3 machines I needed a substantial amount of other windows (>30), on another just having visual studio open was enough. When The Bug happens, the application will have 1 additional frame of input lag (regardless of OpenGL/D3D, how many buffers are used, whether the flip presentation model is used, whether DISCARD or SEQUENTIAL is used). This is because DWM will first drop a frame, and then queue one frame too much. It is the same symptom as if your application has at least 2 back buffers, and doesn't wait after presenting each frame and before processing input for the next frame using DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT (or an equivalent approach using DwmFlush), however this time it is not your application's swap chain that is clogged. Frame timings in the application may be completely normal -- the problem is in the underlying DWM. The application can sometimes resynchronize (and thereby fix The Bug until the next time it chooses to occur) by intentionally dropping a single frame, so that DWM cannot queue another frame exactly once, which will cause the additional frame it had queued up to be flushed. If the attempt was successful, input lag will be normal again. It will look like simulation ran twice as fast for exactly one frame, but no frame is actually dropped as far as visible frame rate is concerned. It is also possible to drop more than one frame, which will increase the chance of success (somehow it doesn't always work), however that will cause visible stutter. Additionally, it is possible that this method is unable to fix The Bug, although I was only able to reproduce this on one of the 3 machines (I wasn't trying very hard though) -- it just so happened that a youtube video was playing in the background. If The Bug occured while it was playing, it was impossible to undo The Bug even with more extreme methods such as reinitializing D3D, recreating the window, or restarting the entire process. Only when the video was paused, or the containing window minimized, it was possible to undo The Bug using the method described above.