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

Issue 688913 link

Starred by 3 users
Status: WontFix
Owner:
█ junov@chromium.org
Last visit > 30 days ago
Closed: Feb 2017
Components:
EstimatedDays: ----
NextAction: 2017-02-15
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

CSS transform and Canvas.drawImage at the same time, it will be delayed

Reported by bps.tam...@gmail.com, Feb 6 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Steps to reproduce the problem:
1. 2 images load use deferred.promise.
2. 1's apply, canvas context drawImage and canvas move use CSS transform animation.
3. it will be delayed more than Firefox.

What is the expected behavior?
Played the same way as Firefox

What went wrong?
The movement seems to have stopped

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: n/a
OS Version: 10.0
Flash Version: Shockwave Flash 24.0 r0

I make reappearance site. please look it:

https://jsbin.com/gufuviz/

Please press "Next" in the upper left after the image is displayed

// FWIW
After setting [ use Hardware acceleration] check to [ OFF ], the behavior became good.
Why does not use Hardware acceleration better than use that?

Comment 1 by nyerramilli@chromium.org, Feb 6 2017

Labels: Needs-Milestone

Comment 2 by kochi@chromium.org, Feb 8 2017

Components: -Blink Blink>Animation
NextAction: 2017-02-15
Status: Available (was: Unconfirmed)
Confirmed Chrome 56.0.2924.87 (Official Build) (64-bit) (Linux) and
Firefox 51.0.1 (Linux) behave differently.

Can animation team triage this?

Comment 3 by suzyh@chromium.org, Feb 8 2017

Status: Unconfirmed (was: Available)
Setting to Unconfirmed so it will go via our usual triage process.

Comment 4 by suzyh@chromium.org, Feb 8 2017

Status: Untriaged (was: Unconfirmed)
Whoops, should be Untriaged

Comment 5 by alancutter@chromium.org, Feb 9 2017

Components: -Blink>Animation Blink>Canvas Internals>Compositing>Animation
The test case is very large and complex, a simpler and more reliable test case would help us resolve this issue faster.


Given the detail about turning off hardware acceleration fixing the issue it's likely an interaction between compositor animations and updating the canvas content region.
Blink>Animation deals only with main thread animations.

Comment 6 by junov@chromium.org, Feb 20 2017

Owner: junov@chromium.org
Status: Assigned (was: Untriaged)
Based on tracing data. SkPicture playback for the 2D canvas is taking an unreasonable amount of time.  The GPU process does not appear to be busy.  It is CPU overhead in the main thread that is killing performance.

Comment 7 by junov@chromium.org, Feb 20 2017 

Note: Do not investigate this case using a build that has DCHECKSs enabled. There are checks in GrResourceKey::validate() that greatly affect performance by causing excessive re-evaluations of skia GPU resource hashes.

Comment 8 by junov@chromium.org, Feb 20 2017

Status: WontFix (was: Assigned)
The problem seems to be fixed in recent build of Chrome.

In a trace graph generated using Chrome 56, I see GPU readbacks being triggered, which are causing significant lag. In Chrome 58, the problem is gone.  The issue was likely fix by this patch: https://codereview.chromium.org/2625873005/

Closing this issue since there is nothing more to do.

Comment 9 by bps.tam...@gmail.com, Feb 21 2017 

to all.

I really appreciate it! thanks all!

2017-02-21 4:31 GMT+09:00 ju… via monorail <
monorail+v2.390629665@chromium.org>:

Comment 10 by junov@chromium.org, Feb 21 2017 

If you would like to confirm that the issue is indeed resolved, try installing the Chrome Canary channel.  This can be installed without removing your existing Chrome installation.

https://www.google.com/chrome/browser/canary.html
►

Sign in to add a comment