We currently have
a) Compositor::SetNeedsComposite() + CompositorClient::UpdateLayerTreeHost()
b) WindowAndroid::SetNeedsAnimate() + WindowAndroidObserver::OnAnimate()
a) is used by the tab stack
b) is used by the overscroll effects
They are basically the same things nowadays i.e. a) is also really SetNeedsAnimate() since it's needed when the embedder wants to start a tab stack animation. However, it's confusing and seems to have caused an unclear conception of when the embedder needs to call it (it's called requestRender() in Java which we should also rename and document).
If called redundantly, for example when the top controls change which is a renderer-driven animation and the embedder updating layers in response but not driving its own animation, it can mess with our scheduling.
Also, it makes the logic in compositor_impl_android.cc slightly more complicated, and it's a bit subtle where we check for whether a client actually wanted to update something.
It might also be beneficial to track per client if it wants to animate because an unnecessary UpdateLayerTreeHost() (which I think might happen today) would rely on the embedder to track what's dirty efficiently and in the worst case might cause it to go through a lot of layers.
Comment 1 by nyerramilli@chromium.org
, Aug 5 2016