Get the top HN stories in your inbox every day.
user_7832
tverbeure
This is a well known effect. LCD cells must be driven with alternating positive and negative values (of the same magnitude) to maintain an average neutral value, otherwise you get some kind of offset buildup that will result in flicker.
If you alternate every other image with a different color value, you upset that balance.
It will slowly rectify itself for most displays.
nayuki
> LCD cells must be driven with alternating positive and negative values (of the same magnitude) to maintain an average neutral value
This is called inversion and there are interesting web pages on the topic:
* http://www.techmind.org/lcd/
Etheryte
Thanks for explaining, I've run into this on my phone in other contexts and I was starting to think my phone screen is having its last days. Turns out it's expected? Usually I run into this when the screen brightness is at the lowest setting.
tverbeure
Screen brightness is usually modulated by changing the strength of the backlight, not the values sent to the LCD cell array. So flicker induces by inversion doesn’t change when changing brightness.
(There are exceptions: one could dial up pixel values on a dark scene and dial down the backlight settings to save power. But that depends on the image content.)
immibis
So Snow Crash[0] does affect both humans[1] and computers!
Muromec
Damn it, now I have ro read another Stephenson book.
kevingadd
Ah, is this why VRR displays start to flicker once your framerate drops too low? I had always wondered if it was a physical property of LCDs
tverbeure
That’s partially right. There’s also the issue of decay due to the LCD cell not being refreshed. It’s similar to not refreshing a DRAM cell.
But the flicker in VRR doesn’t only happen at lower frame rates. Some panels are more susceptible than others. It’s a headache.
It’s also a serious issue when doing 3D stereo on an LCD panel and having a static scene: alternating frames will display left and right views which may be pixels of different color.
undefined
modeless
Looks way more flickery than a real CRT at 120 Hz on an OLED phone. Maybe 240 Hz would be better.
Edit: I misunderstood and was running the 240 Hz version at 120 Hz. The 120 Hz version doesn't flicker noticeably. It does seem to reduce motion blur for 60 Hz content with a brightness penalty. It doesn't immediately make me feel like I'm looking at a CRT. Maybe it would if I had a 480 Hz monitor. There is a slight rolling banding artifact on my phone, maybe an artifact introduced by the display controller as described in the article.
blensor
I assume some people will approach this as stupidly as I did.
I wanted to see something and clicked on the 120Hz version not knowing what my laptop display actually is and while I am not photosensitive this was quite uncomfortable. Thinking I don't understand what that is supposed to be I clicked on the 480Hz to see if that is better/different and that was even worse. As a hail mary I clicked on the 240Hz and well that really made sense and was actually comfortable to look at.
So if you are like me and didn't really read through the text, this will only work for you if you select the Hz that matches your display ( which kinda is the whole point of why they are doing that ). If it looks bad you clicked the wrong link
BlurBusters
I wish Shadertoy had an easier way to let me change framerate. If you click 480Hz on a 120Hz display, it flickers at an awful 15Hz instead of 60Hz; so you don't want to simulate a 15Hz CRT -- not comfortable.
Retroarch now has this CRT simulator and it will automatically keep it at 60Hz by its default settings; so it's more foolproof in Retroarch than in Shadertoy.
BlurBusters
I'm the author of this shader, here's some tips:
- Throw as much native:emulated Hz ratio as you can.
- 120Hz = up to 50% blur reduction
- 240Hz = up to 75% blur reduction
- 480Hz = up to 87.5% blur reduction
- Calibrate your black levels and white levels (e.g. via TestUFO PLUGE test and White Level tests), since you need all of the levels for the simulated phosphor fades.
- Use SDR mode, not HDR, the math in the shader is designed to the Adobe sRGB curve. I wish I had more direct access to the complex HDR curves and ABL to auto-compensate for Talbot Plateau Theorem.
- Use odd number native:emulated Hz ratio on LCD to make it immune to image retention + slightly better behaviors with LCD 6-bit FRC
- Adjust Gain-vs-Blur and gamma, if there's problems. Using low Gain-vs-Blur will reduce color ghosting. Use 0.5 for 120Hz, and if you're getting too many artifacts, try testing numbers as low as 0.25 for 240Hz to see if color ghosting problems disappear. (A fix will be coming)
- Artifacts reduce dramatically at 480Hz versus 240Hz vs 120Hz, more Hz really helps CRT simulation. More Hz the merrier, for BYOA (Bring Your Own Algorithm approaches)
There will be an improved version of my shader on Github, involving:
- Global refresh mode (like a phosphorescent BFI)
- Color balancing modes
- Black level lifter (to fix any thin dark bands caused by violations to Talbot-Plateau Theorem due to certain displays' crappy handling of below-2% greyscales, etc)
Keep an eye out for it in January 2025, just star the Github repo or wait for Retroarch (etc) to implement the improved version of my shader (after I'm finished deadline work for a client at CES 2025)
BearOso
I adapted this to a retroarch slang shader really quick, and I'm seeing some pretty persistent banding on 120hz to 60hz. It shows up obviously when scrolling the same direction as the fake beam scanout. If you take the shadertoy version and edit the scanout direction to left-to-right and fullscreen it, you can see it there, too. The perpendicular scanout and scrolling the demo uses by default disguises it pretty well.
I guess you probably need a higher ratio for this to work really well.
pipes
Silly question, but what does slang mean, as in I've been using retro arch for years and have always wondered what slang means in relation to the shaders.
BearOso
That's RetroArch's shader preset format: https://github.com/libretro/slang-shaders
Not to be confused with the "slang" shader format that Khronos is looking at to replace GLSL.
pipes
Thanks
kevingadd
Slang is a new shader language with NVIDIA's involvement that can compile to multiple other target shader languages for portability.
pavon
Awesome. I find it so ironic that the main thing tempting me to buy to a high resolution high framerate monitor is the desire to better emulate a low resolution low frame rate CRT.
schmidtleonard
After HD, adding pixels/framerate/depth/brightness is like a clean house: it's hard to articulate the value proposition up front in a way that does it justice and it's easy to talk yourself out of going to the trouble, but once you have it you realize just how good it is.
BlurBusters
Even 480Hz looks great for office use; very ergonomic -- browser scrolling has 87.5% less motion blur than a 60Hz OLED and about 90-92% less motion blur than a 60Hz DELL LCD.
mosquitobiten
I'm not sure but I think this could be used instead of BFI in any game.
redox99
This looks REALLY good on a 240hz monitor. Much better than BFI (which I don't use because it's pretty bad on my monitor)
BlurBusters
Thank you! It's in Retroarch now
ahartmetz
Ignoring the heavy flicker, it seems to reduce motion blur even with the 120 Hz demo running on a standard 60 Hz display. Especially visible on the windows. It doesn't seem like it should work, but it does?
But I find it hard to say that what it's supposed to look like. Motion blur is considered fine and correct in the "film look". Our eyes do crazy processing and can't really be emulated by a display technology without going to crazy lengths with high DPI, high dynamic range, high refresh rate (to emulate certain effects, not because we can properly see 90+ or so Hz) and probably eye tracking.
I think I like the slight (static) pixel blur of CRTs more than the motion-related behavior. The crazy DPI numbers of state of the art screens are seemingly not so much about showing detail than about hiding pixels. Calculating all of these pixels is, in a way, a waste of work. I'm talking about ~100 DPI, i.e. making a decent resolution look nicer, not about making low res crap look blurred instead of pixelated.
empiricus
I appreciate the crazy high dpi very much. Because the text is super sharp, it helps with the focus. I am 48 and my eyes are not perfect. I look at screens for many hours every day and if the text is not sharp enough, I lose focus and everything becomes blurry. But super sharp and bright screens mean the eye can have a feedback loop for the correct focus distance.
empiricus
You need an 120hz display to run the 120hz demo. I am surprised to see that the movement is clearer with the shader. You can follow the objects and they are more stable/more clear.
vslira
I’m a complete layperson on graphics and such, so please someone help me here: does this mean we’re now able to simulate old video game visuals on crt? That would be the best Christmas gift ever
mrob
We're getting closer, but 480Hz is still too slow for a convincing simulation of phosphor decay. 1000Hz will probably be enough.
BlurBusters
It's actually good enough for most content for most people if you're just doing 320x240 retro material.
Also, there's some optimizations coming to make it look even better depending on how good or limited your display is.
yincrash
The 120Hz shadertoy works on the Pixel 8 (and hopefully other 120Hz Android devices) if you go to Developer Options and enable "Force peak refresh rate"
I wonder if there's a way to ask Android Chrome to ask for 120Hz.
yincrash
Ah, the non-developer option setting to enable 120Hz on later Pixels is under "Settings"->"Display & touch"->"Smooth display". With that enabled, Chrome will use 120Hz if power and temperature settings permit it to.
SushiHippie
Thanks for the hint, I had this setting enabled, but it didn't look good on Firefox, but using chrome made it look good!
nyanpasu64
I'm still interested in a "selective MPRT" GPU or monitor setting, that only does black frame insertion on changed parts of an image and a "safety margin" around them. This should reduce flicker on non-moving portions of an image/still screen while keeping moving portions sharper. But this probably isn't useful for office tasks, perhaps video, and high-framerate gaming (but only games running at a lower FPS than the screen can (partially?) redraw).
BlurBusters
For things like a pan -- you have to apply it globally because your eye movements will smear the static pixels and motionblur them across your retinas.
However, the CRT simulator actually is variable-MPRT; it does compress the light emissions as quickly as possible as early as possible. Dim greys, for example are brightened and pushed in an earlier refresh cycle of the series that simulates a CRT refresh cycle.
So dimmer pixels get lower MPRT and brighter pixels get higher MPRT. Any unemitted brightness gets cascaded to subsequent refresh cycle until fully emitted to meet Talbot Plateau Theorem.
Get the top HN stories in your inbox every day.
Just a mini-warning/FYI: running the 120hz test on my 60hz LCD IPad (Air 4) has caused that part of the screen with the crt effect to flicker even after leaving the demo. I don’t know what might cause this but it’s weird and worth a warning to anyone interested in trying this out.
(The flickering is more obvious when the control centre is opened, I managed to take a video of it but it’s only partially clear in it. It’s been about 5 minutes so far and I think the effect has reduced. I’m also quite perceptive to flickers so others might not notice it.)