👾👽🛸 TestUFO Version 3.0 LAUNCHED! 👾👽🛸 Go see the big upgrade. 👾👽🛸

[wiseude]

Wierdly enough since the 3.0 update when I use the Variable refresh rate test simulation it keeps going from "ready" to high cpu consumption and back and forth constantly.Even with just 1 tab open.All other test are fine and can hold ready.
This on desktop firefox.

[Chief Blur Buster]

Wierdly enough since the 3.0 update when I use the Variable refresh rate test simulation it keeps going from "ready" to high cpu consumption and back and forth constantly.Even with just 1 tab open.All other test are fine and can hold ready.
This on desktop firefox.

Are you using the 2D engine or the WebGL engine in the TestUFO Settings? Certain tests perform faster in one or the other engine.

For this, the VRR demo performs faster in 2D mode rather than WebGL mode.

If you're getting high load even for the 2D engine, send me a DM and I'll send you a debug link.

[Chief Blur Buster]

Hoping we see improvement from 3rd parties soon, I haven't been able to get a flicker/stutter-less experience in games using what's available. So for now only this website is flawless.

First, do the DisableDynamicPState registry tweak, and make sure the shader app is HIGHER priority than the content you're trying to apply CRT simulator to.

Other than app-builtins like RetroArch and Vint Video Processor (on steam), there's 3 display mirror apps with the CRT simulator. If separate app, it needs to be higher priority than the stuff you're running CRT simulator on top:

1. Shaderglass
2. Wibble Wobble
3. Depth3D Mirror soon (private beta now, wait a few weeks)

[wiseude]

Wierdly enough since the 3.0 update when I use the Variable refresh rate test simulation it keeps going from "ready" to high cpu consumption and back and forth constantly.Even with just 1 tab open.All other test are fine and can hold ready.
This on desktop firefox.

Are you using the 2D engine or the WebGL engine in the TestUFO Settings? Certain tests perform faster in one or the other engine.

For this, the VRR demo performs faster in 2D mode rather than WebGL mode.

If you're getting high load even for the 2D engine, send me a DM and I'll send you a debug link.

where can I switch to the other engine?


Edit:Nvm I found it.It's canvas 2d already.

So it's happening on 2d canvas :/

[Chief Blur Buster]

Edit:Nvm I found it.It's canvas 2d already.

So it's happening on 2d canvas :/

You might be using a dual-GPU system (internal GPU and NVIDIA/AMD GPU).

1. Go to chrome://flags/#force-high-performance-gpu in Chrome/Edge/Brave
2. Turn the setting on. It will use your fastest GPU on your system.
3. It should probably work better, hopefully.

high-performance-gpu.png (10.95 KiB) Viewed 722 times

This advice helps a lot of gaming laptops too.

I wonder if there's a similar setting in Firefox.

[Chief Blur Buster]

New Press Release:

blurbusters.com/testufo3

- Expanded list of features
- Contains info about all tests
- Instructions for settings screen
- How to make 1000Hz work
- Etc.

[Randomoneh]

I took some screenshots of beam simulator and I see some inverted colors in black portions. Is this to counter effects of slow LCD pixel response or is this something that's needed even on zero pixel response time displays like OLED/inorganic LED?

I guess more general question is - shouldn't beam behaviour (outside of cycle timing) be tuned according to specific behaviour of display (overshoot and whatnot)?

Love your whole mission:)

[Chief Blur Buster]

I took some screenshots of beam simulator and I see some inverted colors in black portions. Is this to counter effects of slow LCD pixel response or is this something that's needed even on zero pixel response time displays like OLED/inorganic LED?

It's not inverted colors. What it does is surge out the photons as fast as possible in the earliest subframes, and then release photons on the later refresh cycles. There's some chroma shifting happening here because sometimes if you're doing an orange shade, you'll have a very bright yellow surge (clamped out at max monitor brightness) followed by a dim red to output the remainder of photons.

Thanks to Talbot Plateau Theorem, it blends normally. Rushing those photons out as fast as possible as early as possible to keep the pulsewidths as short as possible, to reduce maximum amount of motion blur. However, it does have some chroma effects that will require some chroma rebalancing in some future algorithms (adjustable). There will be more improvements, I just have been spending so much time on TestUFO that I haven't had time to make more shaders as soon as I hoped.

I guess more general question is - shouldn't beam behaviour (outside of cycle timing) be tuned according to specific behaviour of display (overshoot and whatnot)?

In theory yes. But realistically, it's too much effort to tune to specific displays. The best is to simply "comply" with Talbot Plateau Theorem and let science do the rest.

However, I definitely want to add some color-correction adjustments to the phosphor fade effect.

This is the world's first GPU shader that can simulate the CRT electron beam scanning in realtime, so both me and Timothy Lottes get the credit. This was a breakthrough even if imperfect, and will only get better as displays improve & shaders improve. More information at Blur Busters Open Source Display Shader Initiative.

[Randomoneh]

It's not inverted colors. What it does is surge out the photons as fast as possible in the earliest subframes, and then release photons on the later refresh cycles. There's some chroma shifting happening here because sometimes if you're doing an orange shade, you'll have a very bright yellow surge (clamped out at max monitor brightness) followed by a dim red to output the remainder of photons.

Thanks to Talbot Plateau Theorem, it blends normally. Rushing those photons out as fast as possible as early as possible to keep the pulsewidths as short as possible, to reduce maximum amount of motion blur.

I understand retro communities are all about simulation being as faithful as it can be to the original but just to confirm - is any part of this shader trying to emulate any possible(?) visual peculiarities of CRT displays or is your implementation (blending transitions between portions) truly the best way to currently implement scanning refresh on modern OLED and LCD displays?

[Chief Blur Buster]

I understand retro communities are all about simulation being as faithful as it can be to the original but just to confirm - is any part of this shader trying to emulate any possible(?) visual peculiarities of CRT displays or is your implementation (blending transitions between portions) truly the best way to currently implement scanning refresh on modern OLED and LCD displays?

Some of what it does is a compromise because we don't have enough subframes yet to do everything even more accurately. Once we have 16 subframes (60Hz CRT emulation at 960Hz OLED) a lot more flexibility is provided, like controlling which color ghosts more, rather than letting it decide which colors to ghost (tradeoff in order to succeed sufficient faithfulness in motion blur reduction).

Sometimes original CRTs have similar behaviors, like how they have color tinted ghosting (e.g. green ghosting because green is longest persistence)

Some of the workarounds in the shader is simply because we're stuck with only 2,3,4 subframes. If you've ever seen a high speed video of a CRT via the Super Slo Mo Guys, you'll see that we'd literally need the full scanrate (~15000 subframes) for full faithfulness. That'd require a ~15000fps ~15000Hz OLED. Ouch!

There are likely going to be several variants very soon, one that keeps it color-equalized (but less blur busting). It already has been improved with global mode (phosphorescent BFI) if you disable the scan direction.