Comment by ben-schaaf
17 hours ago
This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible.
For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering.
Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
> Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
You're right that they avoid unnecessary painting but it is not this granular anymore. It used to be but rendering is so much faster these days where it is cheaper to just render a bit more than tracking dirty regions. It's easily visible on Android where you can enable "Show view updates" and see the entire textbox view updates when the cursor flashes. The docs say the same thing.
https://developer.android.com/reference/android/view/View#in...
Wow, that's quite silly - and might partially explain some of the worsening battery life on Android. GTK4 also removes such an API, but just like those docs say, dirty rects are still calculated internally. You can enable the same visual debugging in GTK4 and see that dirty rects are done the same as they always have been.
Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.
That doesn't mean that the process stops, it runs indefinitely because it has to.
The DOM does this. React does this.
Did you know CSS even invokes the GPU for certain tasks?
You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.
> That doesn't mean that the process stops, it runs indefinitely because it has to.
The processes don't stop, no, but they do pause and go idle, waiting for the next event to come in. Not sure what that has to do with this.
> The DOM does this. React does this.
What does react have to do with any of this discussion, and what do you mean by "this"?
> Did you know CSS even invokes the GPU for certain tasks?
Whether the GPU or CPU does work is unrelated to how frequently and how much of the screen is rendered. Damage regions work just fine for GPU-based rendering.
> You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.
Part of my job is maintaining a retained mode UI library. I've literally written some of the parts that handle damage regions, as well as the GPU-based rendering. But do go on about how I don't know how any of this works.