Hacker News Reader

Comment by blovescoffee | Hacker News Reader

There's definitely a few reasons but one of them is that you have to ask the GPU to do ~60x less work when you render 60x less frames

View on HN

PSR (panel self-refresh) lets you send a single frame from software and tell the display to keep using that.

You don’t need to render 60 times the same frame in software just to keep that visible on screen.

How often is that used? Is there a way to check?

With the amount of bullshit animations all OSes come with these days, enabled by default, and most applications being webapp with their own secondary layer of animations, and with the typical developer's near-zero familiarity with how floating point numbers behave, I imagine there's nearly always some animation somewhere, almost but not quite eased to a stop, that's making subtle color changes across some chunk of the screen - not enough to notice, enough to change some pixel values several times per second.

I wonder what existing mitigations are at play to prevent redisplay churn? It probably wouldn't matter on Windows today, but will matter with those low-refresh-rate screens.

Normally, your posts are very coherent, but this one flies on the rails. (Half joking: Did someone hack your account!?) I don't understand your rant here:

    > With the amount of bullshit animations all OSes come with these days, enabled by default, and most applications being webapp with their own secondary layer of animations, and with the typical developer's near-zero familiarity with how floating point numbers behave

I use KDE/GNU/Linux, and I don't see a lot of unnecessary animations. Even at work where I use Win11, it seems fine. "[M]ost applications being webapp": This is a pretty wild claim. Again, I don't think any apps that I use on Linux are webapps, and most at work (on Win11) are not.

Seriously? What is _this_ comment? TeMPOraL makes perfect sense.

LLMs learned that users have post histories? /s

Android has a debug tool that flashes colors when any composed layer changes. It's probably an easy optimization for them to not re-render when nothing changes.

I never thought about it but you've made me realise that a lot of people in our industry have been so enthusiastically working on random "creative" things that at best no one even asked for and it turns out to hurt the end users in ways no one even knows.

I used to be a front end dev and I always hated that animation was coded per element. There should be just a global graphics API that does all the morphing and magic moves that user can turn off on the OS.

Why? Surely copying the same pixels out sixty times doesn't take that much power?

Copying , Draw() is called 60 times a second .

It isn't for any reasonable UI stack. For instance, the xdamage X11 extension for this was released over 20 years ago. I doubt it was the first.

At the software level yes, but it seems nobody has taken the time to do this at the hardware level as well. This is LG's stab at it.

Apple has been doing this since they started having 'always-on' displays.

So has Samsung, but we're talking mobile devices with OLED displays, which is an entirely different universe both hardware and software-wise.

What’s your metal model of what happens when a dirty region is updated and now we need to get that buffer on the display?

Xdamage isn’t a thing if you’re using a compositor for what it’s worth. It’s more expensive to try to incrementally render than to just render the entire scene (for a GPU anyway).

And regardless, the HW path still involves copying the entire frame buffer - it’s literally in the name.

Thats not true. I wrote a compositor based on xcompmgr, and there damage was widely used. It's true that it's basically pointless to do damage tracking for the final pass on gl, but damage was still useful to figure out which windows required new blurs and updated glows.

You forget that all modern UI toolkits brag about who has the highest frame rate, instead of updating only what's changed and only when it changes.

It was, but xdamage is part of the composting side of the final bitmap image generation, before that final bitmap is clocked out to the display.

The frame buffer, at least the portion of the GPU responsible for reading the frame buffer and shipping the contents out over the port to the display, the communications cable to the display screen itself, and the display screen were still reading, transmitting, and refreshing every pixel of the display at 60hz (or more).

This LG display tech. claims to be able to turn that last portion's speed down to a 1Hz rate from whatever it usually is running at.

The PCWorld story is trash and completely omits the key point of the new display technology, which is right in the name: "Oxide." LG has a new low-leakage thin-film transistor[1] for the display backplane.

Simply, this means each pixel can hold its state longer between refreshes. So, the panel can safely drop its refresh rate to 1Hz on static content without losing the image.

Yes, even "copying the same pixels" costs substantial power. There are millions of pixels with many bits each. The frame buffer has to be clocked, data latched onto buses, SERDES'ed over high-speed links to the panel drivers, and used to drive the pixels, all while making heat fighting reactance and resistance of various conductors. Dropping the entire chain to 1Hz is meaningful power savings.

[1] https://news.lgdisplay.com/en/2026/03/lg-display-becomes-wor...

Thanks. Great explanation.

So it's a Sharp MIP scaled up? https://sharpdevices.com/memory-lcd/

Sharp MIP makes every pixel an SRAM bit: near-zero current and no refresh necessary. The full color moral equivalent of Sharp MIP would be 3 DACs per pixel. TFT (à la LG Oxide) is closer to DRAM, except the charge level isn't just high/low.

So, no, there is a meaningful difference in the nature of the circuits.

Reply on news.ycombinator.com