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.
Viola. NO ZIG ZAG ARTIFACT.
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 http://www.testufo.com/scanskew ...) 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).
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
[*]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.