New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 602831 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Task



Sign in to add a comment

Android: Consolidate browser-side UI animation hooks

Project Member Reported by siev...@chromium.org, Apr 12 2016

Issue description

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.



 
Labels: OS-Android
Cc: mdjones@chromium.org khushals...@chromium.org
Components: UI>Browser>Mobile>CompositedUI

Comment 3 by cmasso@google.com, Mar 7 2018

Labels: -Type-Bug Type-Task

Comment 4 by peconn@chromium.org, Mar 15 2018

Labels: android-fe-triaged
Status: Available (was: Untriaged)

Sign in to add a comment