Extra note, it looks like a whole tile is flickering not only images, as if we're activating a tree with visible un-rendered tiles.

vmpstr@ could you take a look?  Seems quite sever.  I personally notice something like this almost daily.

Hmm that's interesting. It might have something to do with khushalsagar@'s work on animated images. I'll try to repro and investigate.

I'm suspecting this is a top controls issue. If you start the gesture with top controls on, and start scrolling you will end up in a situation where top controls get hidden, but it seems that the active tree still thinks the viewport is smaller (by top controls amount) until you let go of the finger. So as a result, we don't consider the bottom part of the screen to be a part of the viewport. Once you let go of the finger, then we update. After the top controls are already hidden if you start the gesture, the problem doesn't reproduce. 

FWIW this also reproduces on 59. I'm going to remove regression tag, since it seems to be a long standing issue. 

It's been in for a while, but looks like a rather bad product excellence issue.  We should ask release managers about merging back to earlier branches once we know what the fix involves.

Still looking into this.

It seems that the property tree root clip on the active tree is correct considering even partially hidden top controls. 

The root clip on the pending tree, however, stays small as if the top controls are fully visible. FWIW, we've had this problem before, but it was fixed by having synced top controls visibility information (afaicr).

Still looking at this.. +property tree experts

The top controls delta is applied directly on the active tree and modifies only the viewport clip/scroll layers. In general, we don't tell Blink about it until the finger is lifted or the controls reach maximum extent at which point we cause a resize in Blink to the new viewport height. Presumably that's when the pending tree gets updated. AFAIK this has been how it works since the beginning - wonder if we just don't notice because there wasn't much animated content?

Perhaps we just need to mirror the top controls delta to the pending tree as well so we can invalidate correctly?

I think the invalidation is fine, it's just that the pending tree believes its viewport is smaller than it actually is, so content below the (too-small) viewport isn't required for activation so we activate without that content being ready. However, now that it's on the active tree we checkerboard one frame because we're not fast enough to rasterize and then rasterize it immediately, causing this flicker.

Do you know if it's hard to apply the top controls delta? FWIW there's also a bandaid fix that we can apply for the purposes of these activation rects by just expanding the viewport by the height of the top controls if it hasn't been updated yet. (or I guess if it doesn't match the active tree viewport)

The delta is just a single float by which we expand/contract the inner and outer viewport clips so it shouldn't be too bad. There's a bit of nuance in how that works for the outer viewport to ensure we handle scroll clamping correctly under pinch-zoom. The details of that are in LayerTreeHostImpl::UpdateViewportContainerSizes.

Though, I'm not sure if we ever push anything from Active->Pending like this so maybe that might cause other issues but I'm not really an expert in compositing so I can't say.

For your bandaid, you should be able to tell on the pending tree whether the tree reflects the state with top controls hidden or shown. If they're hidden you could just add the entire top controls height to the rect so that we always wait for the "height with top controls hidden" amount of content to be available. It means that sometimes you might block on content that's not really required but that's better than flickering.

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

commit c8bc830d86b90921cebbc428072b4a43f9bec372
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Wed Dec 20 18:42:28 2017

cc: Expand the required rect by top controls sometimes.

If we're on android and there's a chance that we're hiding top controls
(ie we're scrolling), then expand the pending tree required rect by
the top controls height.

This prevents flickering due to a smaller than actual viewport on the
pending tree. It doesn't cause any harm other than potentially slower
activation time. However, since we're in a scroll we prefer smoothness
anyway and this prevents visual bugs.

R=ericrk@chromium.org, vmiura@chromium.org

Bug:  794456 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: Iee0d23abdd0289b0c6b9c0ddbccbdb81188ba932
Reviewed-on: https://chromium-review.googlesource.com/837107
Reviewed-by: Victor Miura <vmiura@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Commit-Queue: vmpstr <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525383}
[modify] https://crrev.com/c8bc830d86b90921cebbc428072b4a43f9bec372/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/c8bc830d86b90921cebbc428072b4a43f9bec372/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/c8bc830d86b90921cebbc428072b4a43f9bec372/cc/trees/layer_tree_impl.h

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

commit 885ad6282f8ce39f2415f23a9c2ff0e042792739
Author: Eric Karl <ericrk@chromium.org>
Date: Tue Feb 13 09:05:06 2018

Account for bottom controls height in scrolling pending tree workaround

We previously landed a fix to address edge cases where the top bar was
hidden but the pending tree wasn't updated to account for the new size.
This workaround needs to be applied for the bottom bar as well.

R=vmpstr@chromium.org

Bug:  794456 , 806032
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I8bf88667b7f1032f56ebd55226821e74ba902306
Reviewed-on: https://chromium-review.googlesource.com/915046
Reviewed-by: vmpstr <vmpstr@chromium.org>
Commit-Queue: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536301}
[modify] https://crrev.com/885ad6282f8ce39f2415f23a9c2ff0e042792739/cc/layers/picture_layer_impl.cc