[ben-schaaf]

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.

[Rohansi]

> Wow, that's quite silly - and might partially explain some of the worsening battery life on Android.

It's likely the same on iOS. You'd have to try implementing it to really see why it isn't practical.

Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region. Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.

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

Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.

[ben-schaaf]

> Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region.

The way this is done everywhere is to invalidate the entire area of the button. Buttons usually change background on hover/click anyway, so it just doesn't make sense to do more. Text input is special because these widgets can be very large, sometimes spanning the whole screen, so you want fine-grained dirty regions.

> Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.

I've never heard of anyone adding a general Widget-Level cache, considering that most UI elements don't change position that would be quite expensive. In any case the rendering is still a "pure" function regardless of whether you're using dirty regions or not, so not sure what you're trying to say here.

> Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.

That is definitely weird, but it still clearly shows that the regions are being tracked.