Layer squashing causes incorrect rendering while scrolling in Gmail

Layer squashing causes incorrect rendering while scrolling in Gmail

RenderLayer::boundingBoxForCompositing knew how to exclude RenderLayers that
had their own composited layer mapping, but it didn't know how to exclude
RenderLayers that paint into grouped backings.

R=vollick@chromium.org
BUG=370667
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=173653

[abarth-chromium, 2014-05-08 13:58:21]

I still need to make my test case into a proper layout test.

[Ian Vollick, 2014-05-08 14:40:10]

I think there might be some text diffs due to changes in composited layer
bounds, but this LGTM if the bots are happy.

https://codereview.chromium.org/271863003/diff/20001/Source/core/rendering/Re...
File Source/core/rendering/RenderLayer.cpp (right):

https://codereview.chromium.org/271863003/diff/20001/Source/core/rendering/Re...
Source/core/rendering/RenderLayer.cpp:3432: if (options !=
ApplyBoundsChickenEggHacks && node->layer()->compositingState() !=
NotComposited)
I was worried that if node->layer() was squashing, that it might be squashing
into us. I don't think that will ever happen (argument to follow*), but even if
it did, Adam pointed out offline that it wouldn't matter: the bounds we're
computing here are distinct from the bounds of CLM::m_squashingLayer whose
bounds are calculated elsewhere (in CLM::updateSquashingLayerGeometry).

* We only squash layers that a) overlap, b) are assumed to overlap, or c) have a
"scroll parent".

For the overlap cases, if we were to try and squash the two layers it would mean
that they both overlap (or are assumed to overlap) some composited content. But
if one layer was a descendant of the other, the child should have painted into
the parent naturally and shouldn't have been separately promoted/squashed. So
this situation should never happen.

For the scroll parent case, it's also impossible. A layer has a scroll parent if
its scrolling ancestor is not actually an ancestor in the composited layer tree.
And only the root of the composited subtree that scrolls with this non-ancestor
gets assigned a scroll parent (the descendants get taken along for the right).
It's also worth noting that we only squash layers that scroll together
(otherwise we'd have to repaint every time they moved). So if we're trying to
squash a layer with a scroll parent into us, it means that that we've both
decided to be composited, and that we scroll together. If that were true, we
should be the one with the scroll parent pointer!

So, given the above, it might make sense to add a sanity-check ASSERT here to
document our assumptions, or at the very least a comment.

[abarth-chromium, 2014-05-08 15:09:43]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-05-08 15:10:43]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/abarth@chromium.org/271863003/2

[abarth-chromium, 2014-05-08 15:25:44]

The CQ bit was unchecked by abarth@chromium.org

[abarth-chromium, 2014-05-08 15:29:17]

The CQ bit was checked by abarth@chromium.org

[commit-bot: I haz the power, 2014-05-08 15:30:03]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/abarth@chromium.org/271863003/50001

[chrishtr, 2014-05-08 15:36:06]

lgtm

[commit-bot: I haz the power, 2014-05-08 16:39:46]

Change committed as 173653