Blur Busters Forums

Hello everyone I've known about BlurBusters since about 2012/2013 when Mark Rehjon popped into the scene albeit some websites banned him for what they consider spamming. It's great this website was created but I've noticed people haven't discussed certain things in regards to some technologies out there or implementation of technology.

As it stands now my knowledge is based on me entering the internet and learning about this. I have no experience with the things found among your site. It's interesting and I understand it intellectually but I don't use any of the technologies available. As back in around late 2012/early 2013 I decided to quit gaming and focus on other things. I have not played a actual game in about 8 years. Most of my aspect is gaming wise as it's the fastest mode of visual reproduction but I can see people wanting it in movies and other media.

Anyways I'm talking about GSR or Global Scan-rate a.k.a. F-SRR or Full-Screen Refresh Rate. First before mentioning this I have done, years ago about 3 years ago research on this and while finding nothing on various websites or even scientific websites. I did run into an AVSforum post someone made about just the same tech Global Scan-rate, I can't find their post albeit it was searchable in their: Future tech display forum section, the title was something along the lines of Future scanning technology: Global Scan-rate. Or something to that nature.

The person and the replies given mentioned circuits to produce such a thing requires expensive wise circuits either pixel wise or sub-pixel wise or maybe a circuit that controls both pixels and sub-pixels. Each pixel/sub-pixel would need a circuit driving up costs.

Interlaced Scan: performs interleaving of fields such as odd then even 1, 3, 5, 7 etc.etc. and then 2, 4, 6, 8 etc.etc.

Progressive Scan: performs a sweep of progressive 1, 2, 3, 4, 5 etc.etc. visually wise Progressive looks the best but suffers some motion limitations such as spatial limitations due to Interlaced scan producing double-pumped levels of scanning. Higher refresh rate and higher framerate dictate motion blur reduction.

Global Scan: I assume in my opinion a memory buffer is used to keep the entire drawn image and then the entire image is scanned completely in one shot. So it looks like a flash from a camera a full-screen refresh rate.

Besides costs which I assume can only be handled by R&D divisions of major display manufacturers or subsidies done by Universities.

Why is it no one has performed a Global Scanrate whereby say 75Hz there are 75 full-frames displayed near-instantly at the user. In other words no progressive rather full-screen. I'm very surprised that this type of information isn't readily available even theorycrafted by display users or companies even the AVSforum post was a funny coincidence in finding someone who thought along the lines of said display scanrate. It seems even paywall websites don't have this information or it's paywalled to hell and back and the only way to acquire such information is to spend lots of money on various scientific research papers.

I'm aware recently reading that LCDs particularly those which insert black-frames for the purpose of clearing an image from the buffer and reduce motion blur do perform global scanrates in the sense the image is flashed entirely black. But that is just a quirky way of reducing and or eliminating montion blur or excess motion blur. My question is in regards to the very image displayed and "drawn" on the screen. Rather than progressive, a flash out complete of the entire image to further reduce motion blur and also reduce the who zig-zag pattern experienced by some people who've witness back in the CRT days more often than not the various scanout degrees from top to bottom. I assume LCDs experience similar actions in a more subtle way as their nature is a fixed display and more 2D rather than 3D nature like the 3Dness of CRTs due to the hollow section of the tube producing certain distortions whether measurable by the user or by scientific equipment.

Anyways is there a specific reason why Global Scanoutrate has not been investigated as sourced of future scanning technologies? besides costs which I don't care about. I'm surprised people don't want to invest in new ways of using the display.

Firstly, both cables and displays refresh top-to-bottom. Here's a high speed 960fps video of the TestUFO test www.testufo.com/scanout



In addition, there are several more High Speed Videos of Display Refreshing if you want to see what an IPS, TN, and OLED looks like refreshing in real time.

Global instant scan only for the display is generally not lag-desirable because:
- Cables are 1D serializations of 2D data: Finite-speed frame delivery (refresh cycles)
- Most panels are row-column addressed: Finite-speed dislay refreshing
- Sub-refresh latency is possible if you sync frame delivery and display refreshing (already done in most esports displays)
- Sequential scan artifacts are insignificant the higher the Hz: Scanskew effect www.testufo.com/scanskew
- Global scan would be more latency than sequential scan as a result since we don't have infinite-speed cables. Because of refresh transfer. To speed things up require infinite bandwidth which is not possible.

DLP is the closest thing to global scan today. It outputs the first 1-bit full screen field in as little as 1/1440sec or 1/1920sec. But it has to buffer the incoming refresh first (e.g. 1/60sec for 60Hz off the cable). So DLP has mandatory lag because panel refreshes faster than the cable, and has to buffer.

Today’s gaming monitors can refresh on the fly, cable scanout in sync to panel scanout. So the finite bandwidth of a cable is spewed in darn nearly realtime onto the screen on nearly all esports monitors nowadays. This makes sub-refresh latency possible.

Lowest lag is achieved when cable scanout is in sync with panel scanout. That way, each pixel is laglessly refreshed, like a CRT, www.blurbusters.com/scanout .... This is also why VSYNC OFF works so well in equallizing latency throughout the screen surface.

We have something already that gets closer and closer to global scan, called Quick Frame Transport:
viewtopic.php?f=7&t=4064
This is a good compromise for VSYNC ON workflows, the cable frame delivery combined with the top-to-bottm sweep is faster too. As close as possible to infinite bandwidth, but still matched.

The higher the Hz, the display more behaves like global scan. So the problem is slowly solving itself already -- via faster delivery of refresh cycles (frames) and faster scanout -- both of which can be in sync with each other.

I spin a converse rheoretical question: If a cable AND display can global scan instantly with no lag, what’s stopping it from doing it 1000 times a second instead of 60 or 120? We’d have true 1000 Hz displays already. (Actually, DLP can do it already, though at color depth limitations).

Thusly, the path to your desired lagless global refresh is automatically part of the 1000Hz Journey.

So any lower framerate, e.g. 250fps or 333fps can be delivered (cable) & refreshed (panel) in 1/1000sec on a 1000Hz monitor.

Chief Blur Buster wrote: ↑

12 Oct 2020, 01:42

We have something already that gets closer and closer to global scan, called Quick Frame Transport:
viewtopic.php?f=7&t=4064
This is a good compromise for VSYNC ON workflows, the cable frame delivery combined with the top-to-bottm sweep is faster too. As close as possible to infinite bandwidth, but still matched.

Quick Frame Transport is "THE" global frame delivery mechanism

To help other readers digest why this is the case, I'm going to crosspost some elements of that thread.

Chief Blur Buster wrote:People who may have heard of a new method of delivering refresh cycles faster. We're very familiar with this, but few people are.

See HDMI Version 2.1 on HDMIFORUM.org which says:

HDMI Forum wrote:HDMI Quick Frame Transport (QFT) reduces latency for smoother no-lag gaming, and real-time interactive virtual reality.

But what the hell is Quick Frame Transport? Well, it's simply a large blanking interval.

First, if you have seen those numbers in a Custom Resolution Utility, they are just simply mapped spatially in signal layout:



Vertical Total = the entire height of this.
And VBI = Vertical Blanking Interval = (The sum of Vertical Front Porch + Vertical Sync + Vertical Back Porch).

Around here, we sometimes call this the Large Vertical Total trick, which also has other benefits such as reducing strobe crosstalk.

Normally, refresh cycles are transmitted one after the other, in tight fashion with a tiny blanking interval:

However, it's possible to scanout quicker, such as delivering 100Hz refresh cycles in 1/144sec:

It's possible to go even further, such as delivering 60Hz refresh cycles in 1/240sec! Basically, a frame-delivery acceleration of 4x factor, for supported platforms.

HDMI Quick Frame Transport, while specified by HDMI, the fundamental technique also works on DisplayPort and DVI connections, since it's simply a large blanking interval. A refresh cycle is transmitted faster, with a longer pause between refresh cycles.

Also, some 240Hz monitors can only scan-out their panels at full velocity (1/240sec). So they have to buffer an incoming slow-scanning 60Hz refresh cycle over the cable, before scanning-out in 1/240sec. By using Quick Frame Transport, you can do realtime concurrent LCD panel scanout in sync with cable scanout, reducing the input lag of 60Hz or 120Hz signals (e.g. XBox One consoles) on a 240Hz displays.

Ideally, a display has to advertise this feature correctly via the correct EDID/DisplayID info, to inform a computer that it supports a Quick Frame Transport mechanism. However, many existing 144Hz and 240Hz monitors support Custom Resolution Tweaking to create large VBIs, so it would be very easy to add Quick Frame Transport capabilities to these displays, for supported signal sources. Monitor manufacturers should add information to their HDMI EDIDs to include the Quick Frame Transport feature. FreeSync compatible LCDs are relatively easy to make QFT compatible.

(Currently, most 240Hz monitors are very bad at 60Hz consoles, since they only do bufferless scanout at 240Hz -- because they buffer a 60Hz scanout signal and does a full-velocity scanout on 240Hz LCD panels. Unless they're made to support a Quick Frame Transport at 60Hz with a large Vertical Total of >4000 scanlines for a 1080p signal).

Now you understand better!

QFT is good for display pixel refresh sequence that diverges from cable pixel refresh sequence
The faster the Quick Frame Transport (QFT), the more global it can become. In an ideal world, you have infinite-speed Quick Frame Transport combined with infinite-speed display refreshing. But that's just not possible, so Quick Frame Transport is a good way of allowing a computer to transfer refresh cycles faster to the display's framebuffer -- good when scan-conversion is required (e.g. DLP refreshing pattern, plasma refreshing pattern, OLED VR headset refreshing pattern).

QFT is more useful for VSYNC ON workflows; it isn't that helpful for VSYNC OFF
However, if your goal is minimum pixel latency, using VSYNC OFF, then you instead want sub-refresh latency via a display refreshing concurrently with the incoming pixels being delivered on the cable. That's why VSYNC OFF is so amazingly low latency with modern esports monitors; TOP=CENTER=BOTTOM all pixels having sub-refresh latency. You do not need Quick Frame Transport for that.

QFT is possible DIY on some monitors
There's also an advanced method to do a DIY Quick Frame Transport signal (ToastyX CRU + RTSS Scanline Sync) for faster nearer-global delivery for ultralowlag VSYNC ON that's lower lag than anything the graphics drivers can pull off. See More about Quick Frame Transport.

Now when you state infinite-speeds i.e. no speed limits. It implies that there is still a limitation such as for example 144,000FPS/144,000Hz some form of ultra-low microsecond or outright nanosecond based refresh rate or even Gigahertz refresh rate and beyond the various Hertz levels. QFT seems like a syncing tool that while you process 80FPS your screen fires it off at 240Hz speed. In other words about 5 milliseconds of time for 240Hz vs the 80FPS coming in and needing 12.5ms for painting at 80Hz. In essence supercharging data transmission.

But wouldn't technically speaking shouldn't more appropriately the speed should reach to instantaneous transmission with no transmission time in between?

There is a device used in astronomical calculation placed on telescopes for outer space imaging. Apparently behind all the 15 page scientific technical jargon is a device that runs with a single sentence paraphrasing the article "Instantaneous transmission with no transmission time in between." This device is probably limited in the sense it's working with electricity(seems like most electronics work at half- or so the speed of light or 50% SoL) and electronics manipulation i.e. data. But apparently scientist and researches state despite the limitation of the electronic system the calculations are done so quickly funny enough it's speed is instant. The device calculates and moves the telescope calculating any point in space. Just type it in, calculate, done instantly and the telescope moves. Want to see the belt of Orion or see Saturn, type it in, poof already done.

I know supercharging electricity is not done yet in a more boarder sense this QFT system seems like some form of supercharging for data i.e. making electricity move at a set speed such as increasing to speed of light and beyond(more of a Quantum approach) or more appropriately ignoring all speed limits and reach the ultimate speed, instant.

Is this in essence just another supercharger to finally eliminate millisecond-based lag i.e. closer real-time with computer i.e. a syncing of improvement to real-time scan out?

Mathematically, you're asking for "2+2=5" which just isn't possible.

There's no way to instantly deliver (0 microsecond) AND instantly refresh (0 microsecond) a screen. Currently, for the last century -- aka 100 years -- from the 1930s analog TV, to 2020s DisplayPort, picture data is traditionally delivered left-to-right, top-to-bottom, calendar-style, book-style (raster sequence). This has always been the case for all cables and most screens. But let's cover more detail first.

Futuretech wrote: ↑

12 Oct 2020, 17:17

Now when you state infinite-speeds i.e. no speed limits. It implies that there is still a limitation such as for example 144,000FPS/144,000Hz some form of ultra-low microsecond or outright nanosecond based refresh rate or even Gigahertz refresh rate and beyond the various Hertz levels. QFT seems like a syncing tool that while you process 80FPS your screen fires it off at 240Hz speed. In other words about 5 milliseconds of time for 240Hz vs the 80FPS coming in and needing 12.5ms for painting at 80Hz. In essence supercharging data transmission.

Currently, for the last century -- aka 100 years -- from the 1930s analog TV, to 2020s DisplayPort, picture data is traditionally delivered left-to-right, top-to-bottom, calendar-style, book-style (raster sequence).

Pixels (picture elements) are delivered in sequence like letters of a book. The first pixel row is transmitted first, then the next pixel row, then the next pixel row, and so on. Refresh cycles are like pages of a book. Once a page is done, the next page is transmitted, and so on, continually, ad infinitum. This has been true for raster displays from 1930s through 2020s, whether fixed-Hz or variable-Hz.

This has always been the case for all cables and most screens. Basically, a 240 Hz signal delivers approximately 500,000,000 pixels sequentially over the cable (the "Pixel Clock"). 1920 x 1080 x 240 ... If you include the pixels in the porches/sync intervals, it's closer to 600,000,000 pixels per second (~600 MHz pixel clock as seen in a custom resolution utility). And since those pixels are 24-bit color, multiply that pixel clock by 24. That means the display cable is transmitting 14.4 gigabits per second -- your cable to the 240Hz esports monitor is faster than a 10 Gigabit Ethernet cable! To deliver refresh cycles more instantly, just can't be done -- all those refresh cycles have finite-speed delivery. Data over wire is fundamentally serial, whether it's cable, fiber optic, USB, HDMI, DisplayPort, DSL. You can parallelize to some extent (like the channelization of coaxial, or wavelength division multiplexing on optical) but it's still a finiute bits-per-second regardless, and one still can't deliver all pixels of a refresh cycle instantaneously.

You can use compression (DisplayPort DSC) to help speed things up too, and we've now got HDMI 2.1 that can QFT a 1080p refresh cycle in 1 millisecond if the display was designed as such. But that may not help latency-wise before a true-native 1000 Hz panel because:

Remember there's two sync's involved:

• The cable refresh sequence (delivery scanout)
• The screen refresh sequence (refresh scanout)

These can have two completely different scanout patterns. One or the other can be faster or the other, or in sync. For delivery, both transceivers on both ends has to support the operational mode (e.g. HDMI or DisplayPort transceivers capable of faster delivery of refresh cycles, independently of how fast/slow the panel can refresh)

1. Cable/delivery can be faster than display. Display Screen has to buffer (lag is the slowets of the two)
2. Screen/panel can be faster than display. Screen has to buffer (lag is the slowest of the two)
3. Display refreshing pattern different from cable/delivery sequence. Screen has to buffer. (lag is a full refresh cycle minimum)
4. Cable/delivery + Display in sync. No buffering needed for velocity equalization. (sub-refresh latency achieved)

All these situations exist. Neither the cable nor screen can be infinitely fast.

Now, to understand better:

1. Cable/delivery can be faster than display... When the transmission of refresh cycles is faster than the display can refresh, the display has to unavoidably begin buffering anyway. If the scan pattern is compatible (e.g. left-to-right top-to-bottom pixel delivery sequence), then the display can begin refreshing even as the cable delivers faster into the display's memory. This means the last pixel refreshed will be lagged, and limit possible refresh rate, because the display is unable to be fast enough to keep up with the delivery of refresh cycle.
   Example situation: A displays capable of accepting a 60Hz refresh cycle delivered in 1/120sec over cable and then slow-scanning them at 1/60sec onto the screen.
   .
2. Display can be faster than cable/delivery... When the transmission of the refresh cycles is slower than the display, the display has to buffer the incoming refresh cycle before beginning to refresh. Otherwise the refreshing would be completely finished before the last pixel arrived on the cable. Trying to refresh too fast too early from a slowly incoming frame cause glitches, like tearing (even for VSYNC ON) and missing picture data. Firmware bugs that accidentally refresh too soon, show major glitches. However, you can "time" it precisely though, like knowing how fast the picture is flowing in (e.g. 1/150sec delivery of a 75Hz refresh cycle, and the beginning to refresh when the buffer is half full; so that the two scanouts (of cable; and of display panel) "meet" at the final pixel at the bottom of the scan. For a incoming signal 4x faster than the panel, you can time it to begin refreshing when the buffer is 75% full. This is a bit less laggy than waiting until the buffer is 100% full, but still more lag than synchronous scanout.
   .
3. Display refreshing pattern different from cable/delivery sequence.... While the delivery may be top-to-bottom, certain technologies resemble global-refresh behaviors such as: DLP, plasma, etc. But global refresh is a misnomer in a way, because they actually are forced to buffer the incoming signal to do the necessary scan conversion (e.g. plasma fields, DLP 1-bit fields, etc). Once the frame is fully delivered (e.g. 1/60sec for 60Hz), the first field can be essentially globally refreshed (e.g. 1/600sec for plasma 600Hz, or 1/1440sec for DLP 1440Hz 1-bit), as it rapidly sequences temporal dithering techniques (high-refresh-rate low-color-depth, to generate low-refresh-rate high-color-depth). Regardless of how it's done, any mismatch in pixel refresh sequence (e.g. left to right, right to left, bottom to top, diagonal, multiscan, etc) means the input signal being sequentially transmitted, has to be buffered up first before the display can begin to refresh.
   .
4. Cable/delivery + Display in sync.... That's how CRTs long did it, and what most LCD/OLEDs now are able to do. The pixels are refreshed onto the screen practically as soon as they are delivered. There's sitll lag from GtG (pixel transitions) but there's virtually no processing latency. Often a small line buffer (for DisplayPort micropacket dejittering, to lookbehind-only GtG processing, to color processing, to scaler processing). But line-buffer lag is insignificant (usually about a few rows of pixels, so if scanrate is 270 kilohertz (240Hz delivers pixel rows in 1/270,000th of a second), a one-pixel-row buffer for processing purposes may be only 1/270,000th of a second buffer lag. Most of the lag of a modern esports display is simply LCD GtG lag and things like micropacket processing on the cable, since Present()-to-photons can be as little as ~2 milliseconds for every single pixel on the screen (for VSYNC OFF).

Many combinations are incompatible (e.g. not all displays can buffer a faster-delivering refresh cycle for a slower-refreshing panel), so different displays will behave differently for different settings. Quick Frame Transport

(Some useful scan images of multiple different 60Hz behaviours for different 240Hz monitors of the various situations are found, like the vastly different 240Hz scanout processing of an ASUS XG258 240Hz versus an ASUS PG258Q 240Hz, creating a situation where XG258 is low-lag for 60Hz videogame consoles but the PG258Q is high-lag for videogame consoles)

Some screens have global refresh only because they're primed in the dark (in finite time) and then flashed (instantly). Like an LCD strobe backlight where the LCD refreshes in dark and the backlight flashes. Or a double-transitored MicroLED/OLED matrix (one transistor for setting color, another transistor for illumination voltage) which would refresh slowly in total darkness then flash globally with illumination voltage. All "global refresh" mechanisms have this hidden lag. So to reduce lag, might as well refresh while illuminating (like rolling-scan OLEDs, or rolling-scan scanning backlights, which are expensive to do high-quality). After all, Blur Busters used to be scanningbacklight.com in year 2012 before it got renamed -- and started due to discussions of an Arduino-powered scanning backlight.

I have also done beam racing, raster-interrupts-style, with a GeForce/AMD, see this thread about Tearline Jedi, so I'm pretty familiar with the black box behavior of what happens after Direct3D Present() / OpenGL glxxSwapBuffers(), to a pixel becoming illuminated on the screen. Very few people in the world know the Present()-to-Photons "black box" as well as Blur Busters does.

In my Tearline Jedi experiments, I was able to achieve software-to-photons-hitting-eyeballs in subrefresh, for all pixels, whether top edge or bottom edge of screen (TOP=CENTER=BOTTOM=~2ms) on some of the fastest displays on the market. API-to-light in 2 milliseconds for all pixels on a display, even at TN LCD 60Hz (assuming synchronous scanout). That's pretty much all driver overhead + DisplayPort transceiver/packetization overhead + GtG lag.

To get close to lagless global refreshing essentially requires raising BOTH the delivery speeds & refreshing speeds. When that is successfully achieved, there's no valid reason to keep refresh rates low anymore, since otherwise the screen is now idling between refresh cycles.

So, it full circles back: The refresh rate race to high native refresh rates (delivered on cable AND refreshed onto the panel), is the current technological path to towards global refresh in a more lagless way + fieldless(single-pass) way + truecolor way. Even a low framerate (i.e. 50fps) on a 1000Hz panel, gets the benefit of fast delivery (1/1000sec) + fast possibly-concurrent refresh (1/1000sec) for both first and last pixel even for VSYNC ON.

Early History of Rasterization / Scanning
Some history of rasterization (scanning): Serialization of 2D Imagery into 1D Transmission.

The Jacquard Loom, 1804
-- There's the Jacquard Loom of the year 1804 (successful perfecting of earlier Basile Bouchon 1725 punched-paper-tape loom), which automatically weaved pixellated patterns automatically in fabric. It used a loop of punch cards serializing through the loom to control the weaved pattern. (Wikipedia), and eventually was capable of creating dithered images (greyscale self-portrait woven using 24,000 punched cards in 1839 that was woven greyscale at high-definition resolution (over 1000x1000 pixels!). Metaphorically, the punched card loop is the "cable", and the resulting woven fabric is a single "refresh cycle" that took days, weeks or months to rasterize.

The Pantelegraph Fax Machine, 1856-1870s
-- There's the mid-19th century telegraph fax machines that used a pendulum to raster-scan across a surface. Drawings on a surface used a metallized ink to complete a telegraph circuit, which activated a swinging pen on the other end to draw the same image at the remote end. Here's a photo of a 19th century fax sheet, with the obvious rasterization (via swinging pendulum). Wikipedia of Pantelegraph Fax. Metaphorically, the telegraph line is the "cable", and the resulting pendulum-drawn image on paper is a single "refresh cycle" that took more than an hour to rasterize.

So rasterization has been with us for essentially more than two centuries in a manner of speaking -- close to three centuries! -- as a convenient method of serializing a 2D image into a 1D medium. While the ancient tile mosaics is a kind of a rasterized art, it didn't have a serialized transmission medium equivalent like the Jacquard Loom, or the Pantelegraph Fax.

We are currently doing sequential frame delivery -- for the forseeable future -- the art of the finite framerate -- and the art of the raster.

It will be a very long time before we migrate to a framerateless display delivery mechanism that concurrently makes both framerates and rasterization (scanout) mechanisms obsolete. Such stuff may require advanced processing tricks that might add latency (decoding a framerateless signal might be more laggy than decoding a finite-framerate signal), but on the other hand, enables any framerate to be natively rendered from a framerateless signal.