Comment by nh2
2 days ago
But it does. The GPU rerenders your entire screen with all its pixels, even if you change only one. The only thing you can do to avoid that is to not ask the GPU to render a frame. For that you need to reduce FPS.
2 days ago
But it does. The GPU rerenders your entire screen with all its pixels, even if you change only one. The only thing you can do to avoid that is to not ask the GPU to render a frame. For that you need to reduce FPS.
You need a fairly modern laptop to change the screen refresh rate like you're describing. Older laptops do 60Hz (or whatever) refreshes at all times, they can't change refresh rates like that. The compositor should only paint relevant pixels on the screen.
I'm sure that some spinners are horrible and peg the CPU, but unless your machine is older than ~2018 there is something wrong with your setup if spinners (and not intense operations behind them) cause your battery to suffer.
I'm not describing anything about screen refresh rates, which I'm pretty sure are 60 Hz on my laptop even when the CPU+GPU are at 0% and don't draw anything. Compute != monitor refresh.
Compositing is fast and energy efficient. The screen should not be doing a full refresh of the entire display for an isolated change.
Did I totally miss how damage tracking has gone out of fashion, or what do you base this on?
The damage tracking doesn't seem to be effective at reducing the computational cost. Measurement:
Opening https://nh2.me/low-fps-spinners/smooth-spinner.html it doesn't matter if I zoom the spinner to 25% or 500%: Despite the 400x difference in pixels redrawn, the "GPU Process" CPU usage in the "Browser" tab of the Chromium Shift+Esc task manager is equally high.
It only scales down the cost when reducing the FPS.
I am also mystified at how far things have fallen.