Post
by Chief Blur Buster » 18 Jul 2018, 18:19
Depends -- and only if you use VSYNC ON.
With VSYNC OFF, lag differences averages out to nil difference since a random unsynchronized presentation time will average out to being the same regardless of scanout velocity.
Now for VSYNC ON:
That depends on whether presenting the frame is timed to beginning of VBI or end of VBI. The frame and VBI are just endless infinite loop of scanout (like a filmreel) and the frame-presentation intervals can be simply arbitrary in theory -- so fundamentally it doesn't have to add lag. But yes, it is a double edged sword depending on how things are done.
Your question is still a good one for the future of input lag knowledge: Your question should be actually worded as "What is the prevailing frame presentation timing -- beginning of VBI or end of VBI?" -- and this becomes important with large blanking intervals -- and reducing or increasing input lag with VSYNC ON
During variable refresh rate mode, next-frame presentation coincides with beginning of refresh cycles, and historically in fixed refresh rate mode, next-frame presentation coincides with end of refresh cycles. With large VBI, it's favourable to sync next-frame presentation to beginning of refresh cycles.
There is a third-party solution though now. There is a new RTSS scan-line-number-based frame capping feature that will allow frames to sync to the end part of the VBI, rather than the beginning.
Current Windows default driver settings can add lag during VSYNC ON + large vertical totals -- for this purpose, I recommend using the brand new RTSS scan-line-based frame rate capping trick to achieve the "Quick Frame Transport" (QFT) lag-reduction effects. I'd recommend setting the scanline offset to approximately -25 or -50 (negative number) --- to present the frame just slightly before a new refresh cycle begins.
In programmerspeak, basically the Present() or glutSwapBuffers() API timing during VSYNC ON, should ideally now block until the end of vblank before flipping the frame & displaying. Instead of blocking until entry into vblank. This will allow games with lag-optimization logic to synchronize closer to the beginning of active scanout (via inputdelay techniques).
In the long term, graphics drivers will need to fix this to achieve the full "Quick Frame Transport" benefits of large blanking intervals. At least configurable -- e.g. Present() sync to beginning of VBI versus sync to end of VBI.