CSS animations cause rendering jank and make requestAnimationFrame interval inconsistent / lower than 60hz
Reported by
k...@luminance.org,
Aug 26 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0 Example URL: https://dl.dropboxusercontent.com/u/1643240/css-raf-test.html Steps to reproduce the problem: 1. Load the test url 2. Observe solid 60hz (or better) average framerate, consistent intervals 3. Check the box to turn on css animation What is the expected behavior? Average framerate should remain 60 and intervals should remain consistent around 16ms (no frame drops/double frames) What went wrong? Enabling a css animation causes the framerate to become unstable and 1-2 frames are dropped at any given time. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: Version 52.0.2743.116 m Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 If I focus a Gecko-based application (Firefox, Instantbird) the jank becomes even more severe than it normally is when Chrome is focused. This severely affects the Granblue Fantasy browser game, regularly reducing its framerate in battle scenes to 15fps or less. The issue is somewhat random because it appears to depend on the state of their DOM (they heavily use a mix of CSS animations, transitions, and canvas.)
,
Aug 26 2016
I'm not able to reproduce the problem on my (beefy) macbook pro. I thought the difference might be that we've enabled GPU acceleration on Mac (windows is WIP), but force disabling via about:flags still gets 60 fps. Maybe a Window specific issue? Optimistically labelling this as Compositing and Paint with the expectation that the bugs would be in those areas.
,
Aug 26 2016
Here's a self contained version of the dropbox link for permanence in the bug tracker. :) I don't see much variance in frame rate on OS X unless I'm interacting with multiple tabs at once. Then we get hit pretty bad by the serialization the GPU process imposes where one tab doing a very large raster will delay all the other tabs. I think this might be more of the same "windows does vsync really badly" bugs (ex. issue 422000), this doesn't look like paint or compositing per the thread on twitter. It's either a problem in the way we issue commands to the commands in the gpu process, or a problem with our scheduling. The canvas is being drawn to with: canvas.clearRect(0, 0, 320, 320); canvas.fillStyle = "black"; canvas.fillRect(x - 2, 0, 4, 320); kg@luminance.org if you resize the window after starting the animation do the frame drops go away?
,
Aug 26 2016
Resizing window doesn't appear to help. I'll do some more testing a bit later, and try to get a detailed trace file for you.
,
Aug 26 2016
,
Aug 26 2016
Here's a trace from the game that has this issue with all tracing categories checked.
,
Aug 26 2016
Thanks for the trace. Looks like the main thread is spending a lot of time waiting for something from the GPU process. Sunny, could you take a look?
,
Aug 26 2016
Here's a similar all tracing categories trace for the reduced test case in this bug; it may be easier to investigate it since less is going on. The game may be affected by two different issues at once (but one of them is definitely this problem).
,
Aug 26 2016
kg@: could you please try the canary channel, https://www.google.com/chrome/browser/canary.html I can repro the bug on stable version, but not on canary. Thanks.
,
Aug 31 2016
My isolated repro does not cause lag issues in Canary anymore, so I can confirm that's fixed. The other (CSS/layout related as well?) lag issue in this game still reproduces, so I'll file a new bug for it. Thanks.
,
Aug 31 2016
\o/ Marking fixed. Please reopen if I'm misunderstanding. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by k...@luminance.org
, Aug 26 2016