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

Issue 786209 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 782994


Participants' hotlists:
Launcher-Tech-Debt


Sign in to add a comment

Convert Launcher StateTransition animation to ThreadedTransformTransition animation

Project Member Reported by wutao@chromium.org, Nov 17 2017

Issue description

Currently Launcher StateTransition animation is using LayerAnimationElement::BoundsElement.

BoundsTransition will SetBoundsFromAnimation on each OnProgress. Although there is no bound size change during the animation, there is overhead to update animation from ash/views and do a whole commit every frame.

Converting to ThreadedTransformTransition can let compositor optimize and accelerate the animation.

 

Comment 1 by wutao@chromium.org, Nov 17 2017

Blocking: 782994
Will this animation work on mash?

We will eventually need to make the launcher resize vertically instead of moving a large portion of the widget off screen.

For context please see 768437

Comment 3 by vadimt@chromium.org, Nov 17 2017

Labels: Touch-Friendly-Launcher Touch-Friendly-Launcher-Triaged

Comment 4 by wutao@chromium.org, Nov 17 2017

sg.

Currently my change is only replacing the animation type.
I am guessing to make it not fullscreen initially, will have huge changes to app_list_view, not only the animations.
Project Member

Comment 5 by bugdroid1@chromium.org, Nov 17 2017

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

commit 9e32c19691e53f4e3dc20e96721531a3b064b496
Author: wutao <wutao@chromium.org>
Date: Fri Nov 17 20:07:56 2017

cros: Use transform animation for Launcher state transition.

Currently Launcher state transition animation is using layer animation
element of BoundsElement, which will SetBoundsFromAnimation on each
OnProgress. This will generate additional overhead with a whole commit
every frame. This cl converts it to use ThreadedTransformTransition,
which will let compositor optimize and accelerate the animation.

Bug:786209
Test:On Cyan and EVE
Average Smoothness Improved:
Cyan:
1x slow-down-compositing-scale-factor: 88% -> 100%
10x slow-down-compositing-scale-factor: 63% -> 73%

1x slow-down-compositing-scale-factor: 93% -> 99%
5x slow-down-compositing-scale-factor: 46% -> 59%

EVE: 
Change-Id: I960421d89762ff7fcb7c4e230d98137cd3e61170
Reviewed-on: https://chromium-review.googlesource.com/776195
Commit-Queue: Tao Wu <wutao@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517525}
[modify] https://crrev.com/9e32c19691e53f4e3dc20e96721531a3b064b496/ui/app_list/views/app_list_view.cc

Comment 6 by wutao@chromium.org, Nov 27 2017

Cc: kaznacheev@chromium.org
Status: Fixed (was: Available)
Close this one, UMA indicated that there is about 25% smoothness improvement at 50% percentile canary machines from 67% => 84%.

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=f2b7c920aaeda211ff502cc56121f62d


Sign in to add a comment