> That will help save enormous amounts of power: up to 48 percent on a single charge,
Why does refresh rate have such a large impact on power consumption? I understand that the control electronics are 60x more active at 60 Hz than 1 Hz, but shouldn't the light emission itself be the dominant source of power consumption by far?
This is an OLED display, so I don't think the control electronics are actually any less active. (They would be for LCD, which is where most of these low-refresh-rate optimizations make sense.)
The connection between the GPU and the display has been run length encoded (or better) since forever, since that reduces the amount of energy used to send the next frame to the display controller. Maybe by "1Hz" they mean they also only send diffs between frames? That'd be a bigger win than "1Hz" for most use cases.
But, to answer your question, the light emission and computation of the frames (which can be skipped for idle screen regions, regardless of frame rate) should dwarf the transmission cost of sending the frame from the GPU to the panel.
The more I think about this, the less sense it makes. (The next step in my analysis would involve computing the wattage requirements of the CPU, GPU and light emission, then comparing that to the KWh of the laptop battery + advertised battery life.
I interpreted that bit as E2E system uptime being up by 48%. Sounds more plausible to me, as there'd fewer video frames that would need to be produced and pushed out.
Sorry, might be obvious to some, but is that rate applied to the whole screen or can certain parts be limited to 1Hz whilst others are at a higher rate?
The ability to vary it seems like it would be valuable as there are significant portions of a screen that remain fairly static for longer periods but equally there are sections that would need to change more often and would thus mess with the ability to stick to a low rate if it's a whole screen all-or-nothing scenario.
From what I understand, the laptop will reduce the refresh rate (of the entire display) to as low as 1Hz if what is being displayed effectively “allows” it.
With current LCD controllers but new drivers/firmware you could selectively refresh horizontal stripes of the screen at different rates if you wanted to.
I don't think you could divide vertically though.
Don't think anyone has done this yet. You could be the first.
Phones and watches do that with LTPO OLED which I don't believe exists at higher screen sizes although I'm not sure why. This is supposed to be special because it isn't OLED so should be able to get brighter and not have to worry about burn in.
LTPO has problems with uniformity of brightness, that get worse the larger the panels are. On a phone screen, this is usually not perceivable, but if you made a 27" screen out of it, most such screens would be visibly brighter in some corner or other.
OLED iPad dont have always on because of burn-in. Considering people certainly use it as photo frame, notification and time daahboars, kitchen recipe book, etc.
Less of a problem for iphones that unlikely to stay for a week in the same place plugged in and unused.
I'm not sure that there's really anything new here? 1Hz might be lower. Adoption might be not that good. But this might just be iteration on something that many folks have just not really taken good advantage of till now. There's perhaps signficiant display tech advancements to get the Hz low, without having significant G-Sync style screen-buffers to support it.
One factor that might be interesting, I don't know if there's a partial refresh anywhere. Having something moving on the screen but everything else stable would be neat to optimize for. I often have a video going in part of a screen. But that doesn't mean the whole screen needs to redraw.
> HKC has announced a new laptop display panel that supports adaptive refresh across a 1 to 60Hz range, including a 1Hz mode for static content. HKC says the panel uses an Oxide (metal-oxide TFT) backplane and its low leakage characteristics to keep the image stable even at 1Hz.
Anyone who has accidentally snapped the controller off a working LCD can tell you that the pixel capacitance keeps the colours approximately correct for about 10 seconds before it all becomes a murky shadowy mess...
So it makes sense you could cut the refresh time down to a second to save power...
Although one wonders if it's worth it when the backlight uses far more power than the control electronics...
A low refresh rate probably still requires the same display-side framebuffer as PSR.
With conventional PSR, I think the goal is to power off the link between the system framebuffer and the display controller and potentially power down the system framebuffer and GPU too. This may not be beneficial unless it can be left off long enough, and there may be substantial latency to fire it all back up. You do it around sleep modes where you are expecting a good long pause.
Targeting 1 Hz sounds like actually planning to clock down the link and the system framebuffer so they can run sustain low bandwidth in a more steady state fashion. Presumably you also want to clock down any app and GPU work to not waste time rendering screens nobody will see. This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
But why 1hz? Can’t the panel just leave the pixels on the screen for an arbitrary length of time until something triggers refresh? Only a small amount of my screen changes as I’m typing.
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.
> This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
I was under the impression that modern compositors operated on a callback basis where they send explicit requests for new frames only when they are needed.
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.
this is just regurgitating the manufacturer's claim. I believe it when I see it. Most of display energy use is to turn on the OLED/backlight. They're claiming, because our display flickers less, it's 48% more efficient now.
I once had an external monitor with a maximum refresh rate of 30 Hz, and mouse movements were noticeably sluggish. It was part of a multi-monitor setup, so it was very obvious as I moved the mouse between monitors.
I'm not sure if this LG display will have the same issue, but I won't be an early adopter.
Why does refresh rate have such a large impact on power consumption? I understand that the control electronics are 60x more active at 60 Hz than 1 Hz, but shouldn't the light emission itself be the dominant source of power consumption by far?
The connection between the GPU and the display has been run length encoded (or better) since forever, since that reduces the amount of energy used to send the next frame to the display controller. Maybe by "1Hz" they mean they also only send diffs between frames? That'd be a bigger win than "1Hz" for most use cases.
But, to answer your question, the light emission and computation of the frames (which can be skipped for idle screen regions, regardless of frame rate) should dwarf the transmission cost of sending the frame from the GPU to the panel.
The more I think about this, the less sense it makes. (The next step in my analysis would involve computing the wattage requirements of the CPU, GPU and light emission, then comparing that to the KWh of the laptop battery + advertised battery life.
The ability to vary it seems like it would be valuable as there are significant portions of a screen that remain fairly static for longer periods but equally there are sections that would need to change more often and would thus mess with the ability to stick to a low rate if it's a whole screen all-or-nothing scenario.
For example:
- reading an article with intermittent scrolling
- typing with periodic breaks
I don't think you could divide vertically though.
Don't think anyone has done this yet. You could be the first.
The Apple Watch Series 5 (2019) has a refresh rate down to 1Hz.
M4 iPad Pro lacks always-on display despite OLED panel with variable refresh rate (2024):
https://9to5mac.com/2024/05/09/m4-ipad-pro-always-on-display...
Less of a problem for iphones that unlikely to stay for a week in the same place plugged in and unused.
I'm not sure that there's really anything new here? 1Hz might be lower. Adoption might be not that good. But this might just be iteration on something that many folks have just not really taken good advantage of till now. There's perhaps signficiant display tech advancements to get the Hz low, without having significant G-Sync style screen-buffers to support it.
One factor that might be interesting, I don't know if there's a partial refresh anywhere. Having something moving on the screen but everything else stable would be neat to optimize for. I often have a video going in part of a screen. But that doesn't mean the whole screen needs to redraw.
There are also mini LED laptop for creative work. Few more things to check before buying new laptop.
> Source: https://www.pcworld.com/article/3096432 [2026-03-23]
---
> HKC has announced a new laptop display panel that supports adaptive refresh across a 1 to 60Hz range, including a 1Hz mode for static content. HKC says the panel uses an Oxide (metal-oxide TFT) backplane and its low leakage characteristics to keep the image stable even at 1Hz.
> Source: https://videocardz.com/newz/hkc-reveals-1hz-to-60hz-adaptive... [2025-12-29]
---
> History is always changing behind us, and the past changes a little every time we retell it. ~ Hilary Mantel
So it makes sense you could cut the refresh time down to a second to save power...
Although one wonders if it's worth it when the backlight uses far more power than the control electronics...
What's new here is the 1 Hz minimum.
Apple already uses similar tech on the phones and watches.
With conventional PSR, I think the goal is to power off the link between the system framebuffer and the display controller and potentially power down the system framebuffer and GPU too. This may not be beneficial unless it can be left off long enough, and there may be substantial latency to fire it all back up. You do it around sleep modes where you are expecting a good long pause.
Targeting 1 Hz sounds like actually planning to clock down the link and the system framebuffer so they can run sustain low bandwidth in a more steady state fashion. Presumably you also want to clock down any app and GPU work to not waste time rendering screens nobody will see. This seems just as challenging, i.e. having a "sync to vblank" that can adapt all the way down to 1 Hz?
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.
I was under the impression that modern compositors operated on a callback basis where they send explicit requests for new frames only when they are needed.
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.
I'm not even sure how they got their 48% figure. Sounds like a whole-system measurement, maybe that's the trick.
I'm not sure if this LG display will have the same issue, but I won't be an early adopter.
The display has a refresh rate of 120hz when needed. The low refresh rate is for battery savings when there is a static image.
Variable refresh rate for power savings is a feature that other manufacturers already have (apple for one). So you might already be an early adopter.