Stack and other multi-child layout renderers should not call markNeedsPaint if they don't actually change their layout

[apwilson]

Example is a Stack with two children, one always changing and the other never changing. The changing child shouldn't cause the non-changing child to repaint.

[abarth]

Currently layout calls markNeedsPaint unconditionally, but we could do something smarter here if we knew which render object actually painted content. It's possible that the layout change actually only affects render objects that live in their own repaint boundaries.

[Hixie]

I don't really understand this request. Assuming there's no repaint boundary, if we don't repaint the child, how will the child be visible after the parent's layout's changed?

[abarth]

If nothing calls markNeedsPaint in this repaint boundary, we'll just use the recording from last time (which will contain the child). If something does call markNeedsPaint, then we'll paint the child again.

We're currently calling markNeedsPaint when there's nothing actually dirty about the painting in this repaint boundary.

[Hixie]

If the layout changed, then the paint is dirty, pretty much by definition, no?

[abarth]

That's currently the definition, but there are situations where that is an over-approximation. The case that Andrew was hitting is the following:

Stack
  - unpositioned child1
  - positioned child2, with a repaint boundary

Child2 decides it wants to layout. That causes the stack to layout. The stack decides to put child1 and child2 in exactly the same spots as before.

In our current approach, the stack marks itself as needing paint even though it didn't change anything about itself and it doesn't actually have anything new to paint. That causes child1 to repaint, also spuriously even though layout didn't recurse into child1. (In this scenario, child2 did actually change in some meaningful way, but its repainting is contained by its repaint boundary.)

There's an opportunity to do better here by not calling markNeedsPaint unconditionally from layout.

[Hixie]

Oh, I see. Sure.

[eseidelGoogle]

It's not blocking @apwilson, removing pink.

[liyuqian]

@Hixie @tvolkert @HansMuller is there any plan or work in progress for this old issue? (It's currently the oldest in terms of the last update date.)

[HansMuller]

I don't know of any active or planned work on this issue.

[Hixie]

This is definitely something we should fix one day. It's not something anyone has looked at yet.
cc @goderbauer