New issue
Advanced search Search tips

Issue 668396 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

CSS animation takes too much CPU on OSX and drops frames on all systems.

Reported by lukas.we...@gmail.com, Nov 24 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14

Steps to reproduce the problem:
1. Go to https://loopback.cz/c3d43f6/ (or use attached file) on osx (tried on macbook pro retina, and macbook air)
2. Open task manager and see it's taking 4-5% to animate
3. Open same link on windows 
4. Check task manager - same animation takes <1%

What is the expected behavior?
To see same low CPU usage as on windows.

What went wrong?
I have few of this sprites animations on page and they're keeping CPU pretty much busy even when javascript and everything else is idling. Also I found out that this animation I have is for some reason blowing frame budget and this on is not specific only to OSX I see this on windows as well but with less CPU usage.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: da59d418f54604ba2451cd0ef3a9cd42c05ca530-refs/heads/master@{#433437}  Channel: canary
OS Version: OS X 10.12.1
Flash Version: 

Few side notes:
- I did not use background-position animation as it takes even more CPU, like three times more
- First I thought it's HiDPI bound issue but it's not - it's same on Macbook Air with regular screen
- Scaling of background image doesn't have any observable impact on performance. I use double size image because of retina display, but it's same CPU load with smaller image which don't need to be scaled.
- I did check rendering in QuartzDebug and all emoticons are properly promoted to their own GPU context, so they redraw only their rectangle on animation.
 
index.html
847 bytes View Download
default_40_anim.png
5.4 KB View Download
about_gpu.html
49.5 KB View Download
timeline_screenshot.png
268 KB View Download
trace_emoticons.json.gz
935 KB Download
default_20_anim.png
2.5 KB View Download

Comment 1 by timloh@chromium.org, Nov 24 2016

Labels: Performance

Comment 2 by timloh@chromium.org, Nov 24 2016

Status: Available (was: Unconfirmed)
Components: -Blink>Animation Internals>GPU>Scheduling
Labels: Hotlist-Jank
Looking at the trace the renderer, compositor and tile workers are not consuming excessive CPU (plenty of idle time between frames).

Despite this the GPU process is missing a frame every 0.15 seconds.
Could this be a scheduling issue?
I belive I hit two issues: 
1. some problem which causes frame drops - with my sample animation I see this behaviour consistently on windows and osx.
2. high (4-5%) cpu load on osx  
Snímek obrazovky 2016-11-28 v 8.15.07.png
312 KB View Download
Hello, 
any progress on this? It's still see this frame drops on 55.0.2883.95 and 57.0.2973.0 canary. 
Cc: vmi...@chromium.org
Labels: -Performance Performance-Responsiveness
Status: WontFix (was: Available)
I am not sure there is an actionable issue here.  Looking at the two issues in Comment 4:

> 1. some problem which causes frame drops - with my sample animation I see this behaviour consistently on windows and osx.

The animation has 53 steps and a duration of 0.996s.  This means one keyframe 0.0188 seconds which does not align with the typical display frequency of 60Hz (0.0167 seconds).  When you are seeing a skipped frame it is because of this difference.  Changing the duration to 0.882s results in continuous animation.

> 2. high (4-5%) cpu load on osx

Looking at a Chrome trace, there is nothing unusual happening.  Our CPU threads are not very busy.  The display paths for Windows and MacOS vary in some ways which may account for the difference.

It is also possible that the CPU frequency is different between your Mac and Windows.  Since this page does not do much CPU work, the MacBook Air CPU can throttle to a very low frequency.  Comparing CPU % in Activity Monitor is not a reliable comparison.

Sign in to add a comment