Software BFI options?

[Chief Blur Buster]

Bro, OLED displays do not have motion blur, it is minimal there. gtgoled = 0.03ms. This is faster than any existing panels.

GtG is not the cause of motion blur, MPRT is!

Please study the two DIFFERENT pixel response standards first, www.blurbusters.com/gtg-vs-mprt

Also, OLED has motion blur -- just less than LCD. See Why Do Some OLEDs Have Motion Blur?

0ms GtG still has MPRT motion blur!

LCD strobing still outperforms OLED and OLED BFI.

OLED still benefits from BFI though.

Remember, we're considering EYE-tracking motion blur, because the 2nd UFO at www.testufo.com/eyetracking still blurs on OLED -- try it. That's MPRT blur, not GtG blur.

I am in 25 research papers, please see Blur Busters Research Portal to do some educational textbook reading, before claiming OLED has zero blur. Yes, it's less blur, but the blur is reduced only by roughly a third to a half -- in other words, a 240Hz OLED (without BFI) has roughly the same motion blur as a 480 Hz LCD (without BFI).

Also, retina refresh rate is not until 20,000Hz or so, although you need 4x-8x refresh rate differences to easily tell, much like the difference between camera shutter speeds (1/240sec) vs (1/1000sec) -- which is the MPRT blur of a 0ms-GtG panel. MPRT blur of "X Hz" (strobeless) can never average to less than the blur of a specific camera shutter speed:

Try viewing these on your OLED display -- www.testufo.com/eyetracking and www.testufo.com/persistence -- the background behind the moving UFO (2nd UFO) always creates an optical illusion from display motion blur. The optical illusions only disappear on a CRT or short-pulsewidth strobes -- but will always blur (and the blur-generated opical illusion appears) if the display is sample and hold (even if GtG is zero!).





This is because as your analog eyes moves, your eyes are in a different position at beginning of a visible refresh cycle, and at the end of a visible refresh cycle. Your moving eyeballs (tracking eyes) blurs the sample-and-held pixels across your retina, as sample-and-hold display continuously shine their pixels for a whole refresh cycle. So 60Hz = same blur as a 1/60sec camera shutter.

Motion blur (from MPRT persistence, not GtG) is frametime on sample and hold.
Motion blur (from MPRT persistence, not GtG) is pulsetime on impulsed (BFI/strobed)*

A great example of variable persistence BFI educational animation demo is www.testufo.com/blackframes#count=4&bonusufo=1 which demonstrates that MPRT motion blur is pixel visibility time (Regardless of sample and hold, or impulsed), which is the exact remaining display motion blur whenever GtG=0

*For impulsed, there can be duplciate image effects on a flicker/strobed/BFI display, single image if framerate=Hz, double image if framerate=1/2 of Hz (ala CRT 30fps at 60Hz). Animation demo: www.testufo.com/blackframes#multistrobe=2

[krisdee1981]

Anybody tried software BFI on Oled monitors?
I have Alienware AW3423DWF with 164.900Hz. I don't like how BFI flickers at 60Hz on my LG C2, but at 82.450Hz it could be acceptable, and it's easier to hold steady 82.45fps. I already gave up with VRR, because I couldn't stand flickering.
What options do we have, maybe some kind of shader?

[nuninho1980]

Anybody tried software BFI on Oled monitors?
I have Alienware AW3423DWF with 164.900Hz. I don't like how BFI flickers at 60Hz on my LG C2, but at 82.450Hz it could be acceptable, and it's easier to hold steady 82.45fps. I already gave up with VRR, because I couldn't stand flickering.
What options do we have, maybe some kind of shader?

Ok. Sorry, I get no any eyestrain on still modern CRT monitor despite 50Hz (for multimedia with live TV Portugal and videos) and 60Hz (emulators(arcade, PS3...), SEGA, Konami games) as flickering. But I remember I got eyestrain on vintage CRT monitor 14" AOC due to the lack of *purple* glass in 1994. But at 50/60Hz, OLED with BFI is softer flicker ( = more persistence time than) than CRT.

[Maga-pql]

Someone recently posted about using desktopBFI software on the 480hz 1080p mode of the LG OLED (Thread: "psa_desktopbfi_is_a_program_for_half_refresh_rate" on the Oled_Gaming sub reddit)

@chief -- is there any info about how the above compares to the upcoming solution from Asus (PG27AQDP) with their built-in BFI @ 240hz?
Is it a similar experience, or would the Asus BFI be superior?

Deciding between the two screens and was heavily leaning towards the PG27AQDP due to BFI@240hz for frame-limited games like Quake live, but if I can perform the same via software on the dual mode LG, then I'd choose that one instead.

[RealNC]

@chief -- is there any info about how the above compares to the upcoming solution from Asus (PG27AQDP) with their built-in BFI @ 240hz?
Is it a similar experience, or would the Asus BFI be superior?

The built-in BFI should be superior because it will always be frame-perfect. However, I'm not sure Asus knows how to implement BFI correctly. For example, my monitor (XG27AQDMG) is 240Hz and it has 120Hz BFI. Rtings has measured output lag at 120Hz without BFI and it's 6.3ms. 240Hz is 2.6ms.

Enabling BFI makes display lag climb all the way up to 14.6ms. 120Hz BFI means the monitor runs at 240Hz with half the frames being black, so display lag should actually be a bit less than 120Hz non-BFI. But it's actually more than double that latency. I don't know how to explain this other than Asus's BFI implementation showing the black frame before the content frame, which is the dumbest thing you can do with BFI.

If there's another explanation for why display latency more than doubles with BFI, I'm all ears

[Chief Blur Buster]

Enabling BFI makes display lag climb all the way up to 14.6ms. 120Hz BFI means the monitor runs at 240Hz with half the frames being black, so display lag should actually be a bit less than 120Hz non-BFI. But it's actually more than double that latency. I don't know how to explain this other than Asus's BFI implementation showing the black frame before the content frame, which is the dumbest thing you can do with BFI.

No, it's not dumb but VESA EDID fault -- it's the use of common standard VESA timings formula.

It's because of frame transport latency -- the GPU requires 1/120sec to transmit a 120Hz frame from the GPU to the monitor. The monitor has not fully buffered the frame in the first 1/240sec of 1/120sec. It might as well essentially display the first black frame while waiting.

If they used QFT timings instead of VESA timings (Transmit 120Hz refresh cycles in 1/240sec) BFI lag is solved.

When you use ToastyX to modify your 120Hz signal to transmit in 1/240sec, the monitor will do exactly defacto do what you want: Display a black frame 1/240sec sooner. (Not all BFI firmwares are QFT compatible, but I think that one is).

Try it! QFT helps BFI lag ginormously massively -- wish more manufacturers implemented QFT.

Fixed-Scanrate Panels

Fixed-scanrate panels create input lag at refresh rates lower than max-Hz, unless Quick Frame Transport is used to compensate.
I would bottom-align the 60Hz like this, however:



Scaler/TCON scan conversion "compresses the scanout downwards" towards the time delivery of the final pixel row. So about 3/4ths of 60Hz scanout is delivered before the panel begins refreshing at full 1/240sec velocity.

Also, sometimes this is intentionally done by a panel with a strobed backlight or scanning backlights, to artificially increase the size of VBI, to reduce strobe crosstalk (double image effects), by creating a VBI large enough to hide LCD GtG pixel response between refresh cycles (hiding GtG in backlight-OFF).

Flexible Scanrate Panels

However, some panels are scanrate multisync, such as the ASUS XG248 or the ViewSonic XG2431, which has excellent low 60Hz console lag:



Learn more about Quick Frame Transport

For more information about compensating for buffering lag, you can use Quick Frame Transport (Large Vertical Totals) to lower latency of low refresh rates on 240Hz panels: Custom Quick Frame Transport Signals.

The Quick Frame Transport creates this situation:



This can dramatically reduce strobe lag, but Microsoft and NVIDIA needs to fix their graphics drivers to use end-of-VBI frame Present(). Look at the large green block, so frame Present() needs to be at the END of the green block, to be closer to the NEXT refresh (less lag!).

So you see, RealNC, we have a "120hz GPU, 120Hz slow delivery cable, 240Hz fast scan panel" situation during BFI, which forces firmwares to do a leading black frame.

Just like a slowly filling toilet tank (water supply = video cable), you have to wait for the toilet tank to be full before you flush the tank (refresh the screen)

Simple physics and math.

The great news is BFI lag is solvable without firmware updates, DIY on your own existing OLED monitor. Not all OLED firmwares tolerates this, but several OLED firmwares do.

Just download ToastyX CRU and create a QFT mode. That changes it to "120hz GPU, 240Hz fast delivery cable, 240Hz fast scan panel" and prevents the monitor from impatiently waiting for a 120Hz refresh cycle to be delivered before it can fast-scan it at 240Hz.

In fact, you can sometimes even speed it up faster, depending on if you have bandwidth available: "120hz GPU, 360Hz superfast delivery cable, 240Hz fast scan panel". What happens is that the GPU transfers the frame from the computer to the monitor memory in 1/360sec, allowing the visible-frame scanout to start sooner. Some displays actually tolerates overclocked frame delivery without overclocked refresh rate, which sometimes (but not always) reduces latency of MaxHz for monitors that do buffering.

OLED BFI requires buffering anyway and does not realtime scanout (cable=scanout streaming panel), so you sometimes can have frame transport faster than panel scanout, when it comes to buffer-mandatory situations such as OLED BFI. VR headsets often have custom EDIDs that do this.

[RealNC]

Just download ToastyX CRU and create a QFT mode. That changes it to "120hz GPU, 240Hz fast delivery cable, 240Hz fast scan panel" and prevents the monitor from impatiently waiting for a 120Hz refresh cycle to be delivered before it can fast-scan it at 240Hz.

Thanks a lot for the explanation!

Unfortunately, it doesn't work. When I increase VT (or pixel clock in "vertical total calculator" mode) past a certain value, CRU grays out the OK button. For some reason it doesn't allow 120Hz pixel clock to come anywhere near 240Hz pixel clock.

The 120Hz pixel clock is 497.75MHz. The 240Hz pixel clock is 1018.25MHz. I can only raise the pixel clock of the 120Hz mode to 655MHz (that's a VT of 2006.) Any higher than that, and CRU refuses to apply it.

[Chief Blur Buster]

Thanks a lot for the explanation!

Unfortunately, it doesn't work. When I increase VT (or pixel clock in "vertical total calculator" mode) past a certain value, CRU grays out the OK button. For some reason it doesn't allow 120Hz pixel clock to come anywhere near 240Hz pixel clock.

The 120Hz pixel clock is 497.75MHz. The 240Hz pixel clock is 1018.25MHz. I can only raise the pixel clock of the 120Hz mode to 655MHz (that's a VT of 2006.) Any higher than that, and CRU refuses to apply it.

You need to use the DisplayID 2.0 part of the extensions, not the existing default area.

There's multiple EDID standards, you don't want to create the old version of EDID which does not support gigahertz pixel clocks.

Surf to one of those CEA861 extension areas that lets you creates >1GHz pixel clocks in ToastyX. I am away from a copy of ToastyX, so I'll have to post step-by-step later.

[RealNC]

You need to use the DisplayID 2.0 part of the extensions, not the existing default area.

Missed that. I deleted the 120Hz mode from the CTA-861 block and added one in the DisplayID 1.2 block. That works. But unfortunately, the display glitches out with 3000+ VT. Parts of the screen will appear at different places at random. It's a glitchy mess. And that's before even enabling BFI.

[Chief Blur Buster]

You need to use the DisplayID 2.0 part of the extensions, not the existing default area.

Missed that. I deleted the 120Hz mode from the CTA-861 block and added one in the DisplayID 1.2 block. That works. But unfortunately, the display glitches out with 3000+ VT. Parts of the screen will appear at different places at random. It's a glitchy mess. And that's before even enabling BFI.

Damn. Your OLED is incompatible with QFT. Maybe move the excess to the Back Porch instead of Vertical Sync and Front Porch. VRR at low frame rates uses large Back Porch, so a more compatible QFT uses a large Back Porch.