Now that bug 98336 has landed, we can use the top-down implementation to avoid generating a repaint for each child removal. This is currently the case due to RenderObjectChildList::removeChild (see http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderObjectChildList.cpp#L75). This can work as we track the visual overflow during layout so the root's clippedOverflowRectForRepaint includes the children's overflow. There are some exceptions to that though: the example being positioned object way outside it's containing block's box as including them would yield to too overpainting.
Created attachment 169463 [details] Proposed change: Don't repaint our removed children unless they have a RenderLayer and repaint the subtree root.
Comment on attachment 169463 [details] Proposed change: Don't repaint our removed children unless they have a RenderLayer and repaint the subtree root. LGTM. However mitz is the best repaint expert these days, and you may wish to engage him before landing on this and future repaint bugs (I see you have already CC'd him).
Comment on attachment 169463 [details] Proposed change: Don't repaint our removed children unless they have a RenderLayer and repaint the subtree root. > LGTM. However mitz is the best repaint expert these days, and you may wish to engage him before landing on this and future repaint bugs (I see you have already CC'd him). The repaint experts are CC'ed and didn't scream so I assume the patch is not completely broken. I invited Dan to review this patch last week but haven't heard back.
Comment on attachment 169463 [details] Proposed change: Don't repaint our removed children unless they have a RenderLayer and repaint the subtree root. Clearing flags on attachment: 169463 Committed r132591: <http://trac.webkit.org/changeset/132591>
All reviewed patches have been landed. Closing bug.
Re-opened since this is blocked by bug 100499
New Chromium baselines landed in http://trac.webkit.org/changeset/132626.