Blur Busters Forums

Here's an example of the timing diagram of an LCD controller/panel:




If we set the parameters in the CRU according to this




Won't this make the actual scanout work like this diagram? It seems to add lag.

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.

Chief Blur Buster wrote:What is the prevailing frame presentation timing -- beginning of VBI or end of VBI?

OH Yes! Very accurate capture. This is exactly I alway want to know. Thank you for the explanation.

The new RTSS Scanline Sync has presented a new option for DIY Quick Frame Transport!
viewtopic.php?f=2&t=4173

With some RTSS tweaks, it is now possible to configure a VSYNC-ON-lookalike mode where Present() is synchronized to the end of VBI instead of beginning of VBI. This can reduce input lag of VSYNC ON when combined with large blanking intervals (Quick Frame Transport technique). It can be particularly useful for display that can accept a refresh cycle over the video cable faster than it can refresh to the panel -- and avoid frame-buffering latencies of scanrate conversion.