This is expected. We don't automatically promote to composited scrolling when doing so would prevent us from having subpixel anti-aliasing. The reason it would prevent that in this case is that we are drawing the scrolling contents onto a transparent layer so we don't know what color it will eventually be in front of (in the general case). Because of this we disable sub-pixel anti-aliasing when the scrolling contents layer is promoted which degrades the text quality.

Soon, however, if you apply a "background: white" style to the overflow element we will automatically promote while maintaining subpixel text anti-aliasing, see  issue 381840 .

I should mention, you can see the non-subpixel anti-aliasing today if you add "will-change: transform" to the scroller to force it to be promoted.

Yash, you said you saw this page scroll on the compositor in a previous version of Chrome, didn't you?

Yes that's correct. It was scrolling on the compositor until last week. Is this a recent change?

That's strange, the test page doesn't scroll on the compositor for me on low-dpi on	53.0.2785.70 (Official Build) beta (64-bit). Have you tested on stable or beta?

My mistake, we're talking about the main scroller, reopening.

I think http://crrev.com/414515 broke this by causing LayerTreeHostImpl::ScrollBegin to return SCROLL_IGNORED.

@sahel, can you confirm?

Verified that reverting http://crrev.com/414515 fixes this.

The scroll animation logic has still dependency on clearing the currentlyscrollinglayer after each animation. Previously this was done by calling scrollEnd at the end of scroll animation functions.

In my patch I don't clear the currently scrolling layer in scrollEnd to be able to latch a fling to its related scroll.

For now, I explicitly cleared the currently scrolling layer after the scrollEnd. (similar to what I've done in http://crrev.com/414515 for scrollAnimated function.)

The patch is under review now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ebcfc3309fba892b25d84f943d26bbdab6d100ee

commit ebcfc3309fba892b25d84f943d26bbdab6d100ee
Author: sahel <sahel@chromium.org>
Date: Thu Sep 01 00:13:37 2016

currentlyscrollinglayer cleared in scrollAnimatedBegin.

For now the latching is implemented only for mac, and the
scrollAnimation logic is dependent on clearing the scrolling layer after each animation.
The dependency will resolved in follow up patches that will address latching on other devices.

Similar changes is done for scrollAnimated function in:
https://codereview.chromium.org/2256733003

BUG= 642370 
TEST=LayerTreeHostImplTest.SecondScrollAnimatedBeginNotIgnored

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2290233004
Cr-Commit-Position: refs/heads/master@{#415814}

[modify] https://crrev.com/ebcfc3309fba892b25d84f943d26bbdab6d100ee/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/ebcfc3309fba892b25d84f943d26bbdab6d100ee/cc/trees/layer_tree_host_impl_unittest.cc
[modify] https://crrev.com/ebcfc3309fba892b25d84f943d26bbdab6d100ee/ui/events/blink/input_handler_proxy.cc