(09-07-2012 09:06 PM)ToastyX Wrote: [ -> ]Vertical total calculator - Calculates the vertical total required for the specified refresh rate and pixel clock. This can be used to implement Quick Frame Transport (QFT), which can help reduce crosstalk with backlight strobing at lower refresh rates.
Fantastic, and thank you so much for adding this. I do have suggestions (at bottom)
This makes it much easier to do the crosstalk-free modes on the Blur Busters Approved monitors, especially ViewSonic XG2431. We've created a new QFT FAQ for ViewSonic XG2431 on Blur Busters Forums:
Full Panel Zero Crosstalk: Top/Center/Bottom Equally Clear: No Visible Double Images with Strobing!
![[Image: QuickFrameTransport-QFT-740x411.jpg]](https://blurbusters.com/wp-content/uploads/2022/10/QuickFrameTransport-QFT-740x411.jpg)
![[Image: crosstalk-annotated-ANIMATED-XG2431.gif]](https://blurbusters.com/wp-content/uploads/2022/10/crosstalk-annotated-ANIMATED-XG2431.gif)
![[Image: XG2431-QuickFrameTransport-QFT-60Hz-StrobeUtility.png]](https://blurbusters.com/wp-content/uploads/2022/10/XG2431-QuickFrameTransport-QFT-60Hz-StrobeUtility.png)
However, I want to add that Large Vertical Totals incidentally also reduce DLP and OLED lag. They often run in modes where they have to framebuffer the whole refresh cycle in order to do processing.
QFT reduces the latency of those displays quite fantastically, sometimes by tens of milliseconds!
Also, I discovered some displays even support QFT at the full bitrate, e.g. 1/500sec transmission of 60Hz refresh cycles, which turns 16.7ms of lag into 1/500sec of latency.
They don't scanout any faster, but it allows dumping frames from GPU-to-monitor (framebuffer) faster, allowing full-frame monitor processing algorithms to begin sooner (like DLP temporal dithering subfield processing)
Your mileage may vary.
So you may want to also allow people to increase pixel clock to increase vertical total without reducing refresh rate, until the cable's maximum bandwidth is hit. The pixel-receiving circuitry is sometimes 2-5x faster than its max Hz.
We've encontered 60Hz-only displays capable of accepting refresh cycles in 1/240sec, which is useful for framebuffer-processing algorithms (including HDR peak pixel detection post-processing algorithms).
This does not help beamraced-scanout displays like esports LCDs, as trying to QFT 1/500sec a 240Hz LCD while staying at 240Hz, does not seem to provide further latency benefits, and often goes OUT OF SYNC (on panels that synchronizes panel scanrate to signal scanrate).
Not all displays do this.
- Scanrate-matching algorithms goes OUT OF RANGE (panel scanrate matching calbe scanrate)
- Framebuffering-first displays often can accept refresh cycles over the cable sometimes faster than the max Hz.
DLP and auto-relevelling HDR displays necessarily has to framebuffer the whole refresh cycle before processing it (whether for subfields or for detecting brightest pixel and adjusting average picture level, or other algorithms that requires full framebuffering). Sometimes their HDMI/DP transceivers are able to accept pixels faster than max Hz into the display's scaler framebuffer for earlier begin of full framebuffer processing. Sometimes at max bandwidth of the cable too, since some of newer 60-120Hz displays use newer chips that can fill memory faster than the max-Hz refresh cycle, despite not supporting higher Hz.
Remember many 60Hz displays could accept a 120Hz signal that frameskipped. Those displays work perfect with QFT 60Hz, with a non-frameskipped 60Hz that has 8.3ms less latency!
So displays that does unsuccessful frameskipped overclocking, are also candidates for successful lag-reducing QFT, because they were accepting at least specific refresh cycles successfully at faster cable transmissions. Sometimes QFT doesn't increase lag because they key on the beginning versus end of VBI, and if they key on beginning of new refresh cycle before processing previous refresh cycle, there's no lag improvement.
But if their processing begins immediately upon delivery of last pixel, giant latency reductions occur -- several OLED's and DLP's successfully has lower latency with QFT. Not always beyond max Hz, but at least you can lower 60Hz latency massively.
- Sometimes you can only QFT lower than max Hz
- Sometimes you can QFT the max Hz
- Sometimes QFT signal won't lower latency (if processing is keyed to VBI-start)
- Sometimes QFT triggers gigantic latency reductions (on some DLP/OLED).
QFT is not just for strobing; it reduces input lag of several full-framebuffered-processing displays even without strobing, and even certain beyond max Hz (aka displays that don't do submillisecond GPU pixel-to-pixel latency like CRTs and esports LCDs).
Now My Suggestions
1. I recommend adjusting the release notes to indicate there are latency benefits for certain laggy-buffering displays like certain OLED and DLPs. It also even reduces non-strobed LCD latency too with certain sync technologies, especially if you're using Scanline Sync with the tearline adjusted to near bottom of VBI so it's a "end-of-VBI Present()" replacing VSYNC ON's "beginning-of-VBI Present()".
2. I recommend renaming "Vertical Total Calculator" to "Vertical Total Calculator (QFT)" to make sure QFT is part of it. Ideally it should have said "Quick Frame Transport" because it is universal, not just for strobing, but I'd settle for just appending "(QFT)" to make sure users get that assocation. Instead of something obscure like "Vertical Total Calculator".
Searching Google, "Quick Frame Transport" is widely the dominant name for this, especially outside engineer circles, with the most Google search results, and it would be good to keep it in sync with existing Internet information.