41–50 of 186 posts
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...
> 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?
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
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 lo…
Earlier quoted context omitted.
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…
> 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.
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.
Apple introduced variable refresh rate back in 2015. That’s over a decade ago, I’m sure there’s some new tech involved here, but quite the omission.
Perhaps it can do 50Hz, which may be beneficial for emulating PAL systems.
There are also mini LED laptop for creative work. Few more things to check before buying new laptop.
Earlier quoted context omitted.
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
Why? Surely copying the same pixels out sixty times doesn't take that much power?
> 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?
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.