Element.setScrollOffset should integrate with RACUN

Element.setScrollOffset should integrate with RACUN

The setScrollOffset code was either generating a synchronous
invalidation or using repaint-after-compositing-update. This
change removes the former code path.

While the overall test invalidation area is the same in all
tests, we generate more invalidations. The extra invalidations
are caused by forcing a subtree walk of the shifted scrollable
areas and thus forcing an invalidation for some of the descendants.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=181485

[Julien - ping for review, 2014-09-05 17:23:46]

jchaffraix@chromium.org changed reviewers:
+ dsinclair@chromium.org, leviw@chromium.org, wangxianzhu@chromium.org

[Xianzhu, 2014-09-05 17:36:50]

I don't quite understand the reason of the extra invalidations. The test should
track invalidation rects only after the first frame is displayed, why are there
still first invalidations?

[Xianzhu, 2014-09-05 17:59:01]

lgtm. We'd better know more about the reasons of extra invalidations but I think
it shouldn't block this CL.

[Xianzhu, 2014-09-05 18:29:29]

Just debugged fast/repaint/table-overflow-auto-in-overflow-auto-scrolled.html
and found that the extra invalidations are for descendants of the scrollable box
because of "location change". Previously the descendants were not traversed
during tree walk because the scrollable box didn't have any paint invalidation
flag.

- If "location change" is expected, should
not-updating-previousPositionFromPaintInvalidationContainer for the descendants
cause any issue?
- Should we skip invalidation for in-flow descendants of a renderer which has
fully invalidated?

[dsinclair, 2014-09-05 19:30:21]

lgtm

[Julien - ping for review, 2014-09-05 23:09:01]

On 2014/09/05 at 18:29:29, wangxianzhu wrote:
> Just debugged fast/repaint/table-overflow-auto-in-overflow-auto-scrolled.html
and found that the extra invalidations are for descendants of the scrollable box
because of "location change". Previously the descendants were not traversed
during tree walk because the scrollable box didn't have any paint invalidation
flag.
> 
> - If "location change" is expected, should
not-updating-previousPositionFromPaintInvalidationContainer for the descendants
cause any issue?
> - Should we skip invalidation for in-flow descendants of a renderer which has
fully invalidated?

We investigated the issue more. It turns out that this is caused because we
force the descendants to recompute their offset after a location change. This is
unfortunate but expected.

[Julien - ping for review, 2014-09-05 23:11:45]

The CQ bit was checked by jchaffraix@chromium.org

[commit-bot: I haz the power, 2014-09-05 23:13:06]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jchaffraix@chromium.org/541273002/40001

[commit-bot: I haz the power, 2014-09-05 23:19:54]

Committed patchset #3 (id:40001) as 181485