New issue
Advanced search Search tips

Issue 638054 link

Starred by 0 users

Issue metadata

Status: Archived
Owner: ----
Closed: Oct 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

animation performance issue

Reported by nien0...@gmail.com, Aug 16 2016

Issue description

THIS TEMPLATE IS FOR FILING BUGS ON THE ANDROID SYSTEM WEBVIEW. GENERAL WEB
BUGS SHOULD BE FILED USING A DIFFERENT TEMPLATE!

Device name:
Android version:Android 5.1.1
WebView version (from system settings -> Apps -> Android System WebView):49.0.2623.105.0
Application:
webview sample apk with test.html
Application version:

URLs (if applicable):



Steps to reproduce:
(1)Launch any webview App with test.html.
(2)press Down2 button
(3)press Up2 button

Expected result:
App set transform and opacity animation time to 200 ms.
The animation should be smooth and within 200 ms.


Actual result:
There are two animations in order to do the navigation.
One is change opacity and one is transform.
And transform operation use % as unit.
Compositor doesn’t support transform if it depend on the box size.
So navigation animation is done by the blink.
And every frame from blink need a commit.
But v49 gets lot of raster tasks for every commit.
It cause the animation too slow.

Reason for laggy.
Because transform is done by the blink.
But the latency between the prepare tiles and DidFinishRunningTileTasks* tasks depends on 
how many tasks has been inserted into the task queue in the imply thread.
There are lot of tasks during the animation due to the compositor animation.
So there is a long pending tree:waiting during the animation duration.
It causes the transform laggy.

v41 webview doesn't have this issue.


 
test.html
18.6 KB View Download

Comment 1 by boliu@chromium.org, Aug 18 2016

Labels: Needs-Feedback
iirc we never shipped m41, so I don't know where you got that from

you seem to know a lot of the underlying rendering details, so can you take a trace of the old webview build and see what the difference was? What device is this?

only major change in that range I can remember is switching tile uploading to gpu thread

Comment 2 by ericn...@amazon.com, Sep 12 2016

HI 
This bug has 2 issues but are all be improved in v52.
1.Re-raster work for scale causes the pending tree lifetime to be extended. 
We found a fix in Chromium v52 .
https://codereview.chromium.org/1474853002/

2.Latency between the time all did** task are posted versus being processed.
Because there are lot of tasks being filled up the task queue in imply thread .
it takes a longer time to process all of the did** tasks. 
But v52 create other thread to reduce the loading of imply thread.
So the latency has been reduced.


Project Member

Comment 3 by sheriffbot@chromium.org, Oct 13 2016

Status: Archived (was: Unconfirmed)
No feedback was received in the last 30 days from reporter "nien0223@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment