Tracking issue for damage regions

[PoignardAzur]

Damage regions are an efficiency technique: when a repaint happens, we detect what areas of our scene have changed, and we selectively repaint these areas of the render texture, leaving everything else untouched.

Damage regions aren't currently implemented. A hypothetical implementations would have to consider these concerns:

• A damage region feature immediately adds a lot of bug surface. A widget returning an incorrect damage region might fail to update its appearance, for reasons that are hard for their author to debug.
• Damage regions add a lot of complexity that inexperienced developers probably don't want to deal with.
• Any optimizations based on damage regions must consider that widgets can sometimes be painted way outside of their layout box.

I've mentioned a possible design on Zulip:

Olivier FAURE: My current design idea would be: For now users can't request a specific damage region. Instead the framework builds a damage region from the paint_rects of all the widgets that requested a repaint.

Olivier FAURE: I think this would get most of the benefits of damage regions without adding an error-prone API surface to the context methods.

Olivier FAURE: For similar reasons, I think we should have a single damage region. If two widgets have been changed, the region is the union of their rectangles. If the two widgets are two 5x5px squares at the opposite ends of the screen, too bad, we're redrawing the entire screen anyway.

Olivier FAURE: In the long term, I'd amend it to "a single damage region per compositing layer", which I think would avoid most of the pathological unions.