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...

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

for small screen sizes and low information density displays, like a watch that updates every second this makes a lot of sense

it would make a lot of sense in situations where the average light generating energy is substantially smaller:

pretend you are a single pixel on a screen (laptop, TV) which emits photons in a large cone of steradians, of which a viewer's pupil makes up a tiny pencil ray; 99.99% of the light just misses an observer's pupils. in this case this technology seems to offer few benefits, since the energy consumed by the link (generating a clock and transmitting data over wires) is dwarfed by the energy consumed in generating all this light (which mostly misses human eye pupils)!

Now consider smart glasses / HUD's; the display designer knows the approximate position of the viewer's eyes. The optical train can be designed so that a significantly larger fraction of generated photons arrive on the retina. Indeed XReal or NReal's line of smart glasses consume about 0.5 W! In such a scenario the links energy consumption becomes a sizable proportion of the energy consumption; hence having a low energy state that still presents content but updates less frequently makes sense.

One would have expected smart glasses to already outcompete smartphones and laptops, just by prolonged battery life, or conversely, splitting the difference in energy saved, one could keep half of the energy saved (doubling battery life) while allocating the other half of the energy for more intensive calculations (GPU, CPU etc.).

Both my last two XPSes have had shit battery life. Maybe 3.5h when new and only 2h after a few months of use. They also experience a lot of thermal throttling (i7 12700h, 9750h) and newer updates have removed the option of undervolting which used to fix that.

Positive is that the battery life couldn't possibly get worse with newer ones.

Dell has to deal with windows cuts that in half with all the slop and spyware.

They dont buy it for this purpose. Its just end up like that for a lot of people I know since it just weird device between iphone and macbook that end not being used for much.

On such an article it would not go down to 1Hz. It's checking if the image is changing or not.

When PSR or adaptive refresh rate systems suspend or re-clock the link, this requires reengineering of the link and its controls. All of this evolved out of earlier display links, which evolved out of earlier display DACs for CRTs, which continuously scanned the system framebuffer to serialize pixel data into output signals. This scanning was synchronized to the current display mode and only changed timings when the display mode was set, often which a disruptive glitch and resynchronization period. Much of this design cruft is still there, including the whole idea of "sync to vblank".

When you have display persistence, you can imagine a very different architecture where you address screen regions and send update packets all the way to the screen. The screen in effect becomes a compositor. But then you may also want transactional boundaries, so do you end up wanting the screen's embedded buffers to also support double or triple buffering and a buffer-swap command? Or do you just want a sufficiently fast and coordinated "blank and refill" command that can send a whole screen update as a fast burst, and require the full buffer to be composited upstream of the display link?

This persistence and selective addressing is actually a special feature of the MIP screens embedded in watches etc. They have a link mode to address and update a small rectangular area of the framebuffer embedded in the screen. It sends a smaller packet of pixel data over the link, rather than sending the whole screen worth of pixels again. This requires different application and graphics driver structure to really support properly and with power efficiency benefits. I.e. you don't want to just set a smaller viewport and have the app continue to render into off-screen areas. You want it to focus on only rendering the smaller updated pixel area.

There are multiple problems here, coming from opposite needs.

A compositor could request new frames when it needs them to composite, in order to reduce its own buffering. But how does it know it is needed? Only in a case like window management where you decided to "reveal" a previously hidden application output area. This is a like older "damage" signals to tell an X application to draw its content again.

But for power-saving, display-persistence scenarios, an application would be the one that knows it needs to update screen content. It isn't because of a compositor event demanding pixels, it is because something in the domain logic of the app decided its display area (or a small portion of it) needs to change.

In the middle, naive apps that were written assuming isochronous input/process/output event loops are never going to be power efficient in this regard. They keep re-drawing into a buffer whether the compositor needs it or not, and they keep re-drawing whether their display area is actually different or not. They are not structured around diffs between screen updates.

It takes a completely different app architecture and mindset to try to exploit the extreme efficiency realms here. Ideally, the app should be completely idle until an async event wakes it, causes it to change its internal state, and it determines that a very small screen output change should be conveyed back out to the display-side compositor. Ironically, it is the oldest display pipelines that worked this way with immediate-mode text or graphics drawing primitives, with some kind of targeted addressing mode to apply mutations to a persistent screen state model.

Think of a graphics desktop that only updates the seconds digits of an embedded clock every second, and the minutes digits every minute. And an open text messaging app only adds newly typed characters to the screen, rather than constantly re-rendering an entire text display canvas. But, if it re-flows the text and has to move existing characters around, it addresses a larger screen region to do so. All those other screen areas are not just showing static imagery, but actually having a lack of application CPU, GPU, framebuffer, and display link activities burning energy to maintain that static state.