Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

Avoiding Zig-Zag Artifacts of Split Refresh Architectures

Advanced display talk, display hackers, advanced game programmers, scientists, display researchers, display manufacturers, vision researchers. The masters on Blur Busters.

Avoiding Zig-Zag Artifacts of Split Refresh Architectures

Postby Chief Blur Buster » 13 Jan 2019, 22:03

(Crossposted from this AVSFORUM thread)

Race to retina resolution... DONE.
Race to max HDR range... DONE.
Refresh rate race time, baby!
(Living under a stone? Read 1000Hz Journey and then come back.)

Blur Busters Ideas For The Refresh Rate Race

The refresh rate race will be slower than the retina race & HDR race, with true native non-faked refresh rates doubling approximately every 5-to-10 years.

There's a very approximately Blur Busters version of Moore's Law that started roughly 2010 where refresh rates double approximately every 5-10 years, with the first 120Hz gaming monitors, more recently the 240Hz gaming monitor boom, and also the 480Hz experimentals plus the far early-canary 1000Hz I now am seeing.

However, mainstreamization of a refresh rate and frame rate lags approximately 10-15 years afterwards. The first true-120Hz gaming monitors arrived in 2009-2010 (including the ASUS VG236H and the Samsung 2233RZ) and today, mainstream 120fps HFR is only now being standardized.

The refresh rate race can easily be sped up -- with some help by Blur Busters -- if manufacturers put a lot of effort in it, and it's possible that will happen -- e.g. at least "not slower than the NTSC to HDTV transition" even if somewhat slower than the 1080p->4K->8K transition.


240Hz-native OLED timing is indeterminate. But it would be theoretically possible to do it with LG 2019 OLED panels with some upgraded TCONs possibly, if the refreshing architecture is what I think it is, via the use of a 2-channel concurrent scanout technique.

I've written about these diagrams before, but I am now rewriting these into new context. Recycling/spinning them into LG's split-refresh OLED of 2019, to explain how 240Hz could theoretically be engineered into their 2019 OLED via a pair of TCONs:

Faster OLED Backplanes are NOT necessarily needed for Higher Hz


(Except at 240Hz onto a dual-scan 120Hz OLED, instead)

A split-scanout OLED such as the LG 2019 OLEDs, would theoretically be able to do 240Hz this way simply by treating the top/bottom halves as independent 120Hz displays, temporally displacing the next scanout pass by 1/120sec, to make sure that the top-to-bottom continuous sweep belongs to the same refresh cycle (Even as it transfers from one scan segment to the next).

Avoiding Zig-Zag Artifacts of Split Refresh Architectures

This avoids the zig-zag artifact often found in split-scan multi-scan architectures, seen in Charles Poynton's paper


However, if you do it the way I describe, this artifact disappears and you're refreshing at 240Hz true refresh cycles using two concurrent scanouts -- like a two-gun CRT keeping the scanouts contiguous. You'd simply make sure when the other split-refresh begins on the bottom half, it "takes over" the top half scanout continuing the scanout of the same refresh cycle that the top half did.

e.g. For a 120Hz split-channel refresh architecture outputting great looking 240Hz, the bottom half 120Hz must continue scan-out the same refresh cycle that the top half 120Hz did 1/120sec ago. Do not refresh both halves concurrently off the same refresh cycle framebuffer. The raster scanout of the top raster must be the newer frame buffer -- one refresh cycle ahead of the raster scanout of the bottom raster. So the top half "hands over" the scanout to the next segment.


I wrote about this technique in the Theoretical OLED Scanning Patterns thread where there may be a cheap way to create a 960Hz OLED via a 8-channel split refresh architecture -- essentially subdividing the same OLED into 8 different zones.

So, without further ado, theoretically 960Hz OLED can be achieved via running 8-concurrent strips of 120Hz OLEDs that automatically handsover refresh cycles to the next segment below (Creating continous-scanning rasters that are always assigned to their refresh cycles, never multiscanning concurrently the same refresh cycle -- e.g. 8 different frames are always being scanned simultaneously in one continuous sweep per scanout):


Scan algorithm to Eliminate Sawtooth Artifacts & Tearing of Multiscan Displays

For multi-raster approaches like this, you may need to framebuffer a few refresh cycles so each raster is scanning-out their independent refresh cycle. Scanout latency will always match lowest refresh rate, e.g. 960Hz will look like a perfect 960Hz screen, but will have 1/120sec scanout latency and very minor 1/120sec scanskew (See ...) which will be unnoticeable.

The rule is:

  • Display is subdivided into horizontal display-slices, refreshed independently at lower Hz
  • The scanout line above is always the next refresh cycle [aka Frame+1 if framerate=Hz], permanently, at all times.
  • No two rasters are ever multiscanning the same refresh cycle framebuffer.
  • Each raster is its own unique refresh cycle.
  • If there are 8 display-slices, that means 8 different refresh cycle framebuffers are scanning out concurrently
  • When the raster hits bottom of their slices, the display-slice immediately underneath "inherits" the full refresh cycle framebuffer for the next refresh cycle of that display-slice. This is a seamless cascade.
  • The top display-slice is assigned a brand new refresh cycle framebuffer
  • The result is that each raster "appears" to all separately be doing one continuous sweep of their own respective cycles.
  • It takes count of [display-slice count] refresh cycle for the sweep from top to bottom. If there's 8 display slices, it takes 8/960sec to refresh a 960Hz refresh cycle in one continuous top-to-bottom sweep in the seamless cascade.
  • The result is that lower-Hz ends up successfully doing higher-Hz.
  • Each raster will sweep slower than a refresh rate.
  • This 960Hz example have 8 concurrent rasters taking 1/120sec to sweep top-to-bottom.
  • There will be no tearing nor zigzag artifacts, because the continuous raster sweep stays assigned to its own specific frame (thanks to the hand-over cascade).
  • For 960Hz generated from eight 120Hz display-slices, it will look like 960fps @ 960Hz, with 0.8ms MPRT(90%) or 1.0ms MPRT(100%) assuming sufficiently fast GtG. Zero strobing is needed, except it has the latency of 1/120sec as well as 1/120sec scanskew.
  • You may have to buffer a few refresh cycles off the cable (since they transmit one refresh cycle at a time over the cable), to allow the concurrent simultaneous scanout of independent refresh cycles. Latency will be the slowest refresh cycle used (e.g. 1/120sec if using eight 120Hz display-slices to create a 960Hz display).
Follow this rule correctly, and All zig zag sawtooth artifacts disappear.

A Blur Busters idea. Zero zig-zag artifacts.

This Algorithm is still compatible with black frame insertion.

Specific raster passes can still be assigned black frames too! This technique can do 120fps with 1/960sec persistence.


(Each rolling scan window -- at the granularity of the displayslices available -- are separate frames of separate refresh cycle)

This Algorithm Is Compatible With VRR

NOTE: Depending on capabilities, and whether or not it is possible to attach 2 TCONs, it may even be possible to do 240Hz VRR on LG's 120Hz dual-scan OLED panel, given sufficient modifications, and sufficient cable bandwidth.

It is also possible to do a VRR-cascade with this algorithm.
  • All display slices must be VRR compatible, capable of variable blankings
  • Simply make the top display-slice immediately refresh on a variable refresh cycle received from the computer (variable blanking intervals for all display-slices)
  • Once the raster hits bottom of the display-slice, immediately chain-over that to the next display-slice: Immediately begin refreshing the display-slice right immediately underneath.
  • Basically, a displayslice's refresh cycle triggers is daisychained from when the displayslice immediately above finishes completing refresh cycle.
  • Continue cascade in one continuous sweep. So the concurrent-multiscan approach is VRR-compatible.
  • You still need to keep [displayslices] buffers of refresh cycles from the computer, due to the separate-refresh-per-scanout rule
This would work for 2-displayslice, 4-displayslice, and 8-displayslice, possibly (even) including LG's 2019 OLED panel assuming this algorithm is followed, if all displayslices are VRR-compatible.
[*]Properly done concurrently, you have variable-distances between the displayslice boundaries.[/list]

If anyone is spinning their heads and needs training to explain VRR multiscan without zigzags....ok, we're getting into "hire me and fly me in as a PowerPoint trainer for your display engineers" territory.... It's really simple to my brain, but a lot of algorithms require custom purpose-built TestUFO animations running in slow-motion for me to explain. I do this from time to time.

No faster backplanes needed.

This specific idea of mine is patent free as far as I know, though double-check your patent searches. I originally wrote about this over 1 year ago in year 2017, so not patentable, I intentionally put this idea out in the open. Permission hereby granted to use idea, e.g. to pull off 240Hz successfully from a 120Hz OLED. Yes, manufacturers including LG, you have my permission to use this Blur Busters idea for your display at no charge. You're welcome.

EDIT: Even a prototype exists! It's easy to test this experimentially with an Arduino and a small LED matrix. I have already demonstrated it with an Arduino LED matrix like those old 1980s marquees. Done, that. Just a low-rez prototype (32x32 pixel). Confirmed refresh increase effect with zero zigzag artifact. So prototype done, just a minor modification of an old Charles Poynton test...and yep! Dead simple. It experimentally proves this can be scaled up.

Refresh rate increase via zig-zag-free multiscanning algorithm! Yes, it requires an octo-channel OLED, but it's potentially doable with today's technology

AI interpolation will help fill the missing 1000fps equation

Video sources will now become the limiting factor until ultra-high-framerate interpolation is done, or ultra-high-framerate video is done. (e.g. 100fps->1000fps versions of Oculus asynchronous timewarp 45fps->90fps nearly laglessly).

Ultimately, it can just take only a little extra GPU silicon to multiply frame rates virtually laglessly when given realtime high-Hz input from controllers (1000Hz+ mice, 1000Hz+ head trackers, etc) continually feedbacking into an AI interpolator to make the interpolator less blackbox and more accurate-guessing. That's the key to making 1000fps nearly lagless from a 100fps game frame rate source, by approximately ~2025-ish, without needing unobtainum GPU. I deem this universe "Frame Rate Amplification Technologies".

And I already own such a "Frame Rate Amplification Technology" (FRAT): Oculus Rift VR, which converts 45fps->90fps darn near laglessly and mostly artifactlessly.
Head of Blur Busters - | | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors
User avatar
Chief Blur Buster
Site Admin
Posts: 6083
Joined: 05 Dec 2013, 15:44

Re: Avoiding Zig-Zag Artifacts of Split Refresh Architecture

Postby Chief Blur Buster » 15 Jan 2019, 17:07

Oh... and remember those old dual-scan LCDs from 20 years ago?

Those old dual scan laptop LCDs from 20 years ago used to have zig-zag artifacts (stationary tear-line in the middle)

But my algorithm eliminates that problem. True refresh rate increase effect without the zig-zag artifact.

So you could do dual-scan LCDs using my algorithm.

The vertical microwires may need to be upgraded to carry extra current for concurrent rasters (dual-scanning, quad-scanning and octo-scanning), but would not need laws-of-physics modifications. The horizontal scan rate remains unchanged during refresh rate doubling/quadrupling/octupling! So you're not refreshing pixels faster than laws of physics.

It's simply an engineering problem of finding ways to connect multiple TCONs to the left/right edge of a panel; to allows the same display to behave as multiple independent, concurrent, displayslices -- in order to achieve the refresh-rate-increase effect. This may be a daunting engineering issue to connect more ribbon cables (in odd splits) to the panel, but at least this doesn't require faster LCD molecules. This may require panel fabrication changes to make multiscanning possible again on an LCD, but then, this unlocks refresh-rate-increase with this zig-zag-free algorithm.
Head of Blur Busters - | | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors
User avatar
Chief Blur Buster
Site Admin
Posts: 6083
Joined: 05 Dec 2013, 15:44

Return to Area 51: Display Science, Research & Engineering

Who is online

Users browsing this forum: No registered users and 0 guests