Animation jumps erratically when inside a container with overflow:hidden and animated width/height |
|||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36 Example URL: http://codepen.io/lucaskovar/pen/qaJBjE Steps to reproduce the problem: Visit http://codepen.io/lucaskovar/pen/qaJBjE What is the expected behavior? The user should see a smoothly animated image that is gradually revealed/hidden by animating the height of a container element with overflow:hidden What went wrong? On Firefox and Safari, the animation is smooth, but on Chrome, the animation occasionally makes large, sudden jumps. I thought the problem may be specific to animating height, but I get similar artifacts if I animate clip: http://codepen.io/lucaskovar/pen/LRgYgk ... or -webkit-clip-path: http://codepen.io/lucaskovar/pen/xEybxO For reference, if you remove any attempt to animate the container's height, but otherwise leave the content unchanged, the animation is smooth: http://codepen.io/lucaskovar/pen/zKmxGA Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 54.0.2840.59 Channel: stable OS Version: 10.11.6 Flash Version: Shockwave Flash 23.0 r0
,
Oct 19 2016
Looks like this is might be due to an interaction between composited animations and non-composited animations. @keyframes reveal-keyframes is not composited due to the presence of height values while reveal-keyframes-2 is composited. If I add a noop "margin-left: 0" to one of reveal-keyframes-2's keyframes to force it off the compositor I no longer see the jumpiness.
,
Oct 19 2016
Able to reproduce the issue on windows-7, Mac 10.11.4 and ubuntu 14.04 using chrome stable version 54.0.2840.59 and canary 56.0.2894.3 This is regression issue broken in M50. Please find the bisect information as below Narrow Bisect:: =============== Good ::50.0.2638.0 -- (build revision 372857) Bad::50.0.2639.0 -- (build revision 373124) ChangeLog: ================ https://chromium.googlesource.com/chromium/src/+log/85c03e554ef873cb0a156309dd7249f2d1a62792..68b47b29bafb2c4bdfc40049829627ba08aeb266 Possible suspect ================== cd81fc01b4fc01c843905ddc77beb452a6942d2c Review URL: https://codereview.chromium.org/1653063002 zmo@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Thanks,
,
Oct 19 2016
Mo, could you please check whether your CL is the culprit.If yes, please target a fix for M55.
,
Oct 19 2016
I really don't think so.
,
Oct 20 2016
This bug appears to still be present in revision 370000, I'm going to call this a non-regression issue.
,
Oct 26 2016
,
Nov 23 2016
,
Nov 23 2016
The provided code implies that two animations produce deterministic result if added together. This is not true if you run them on different threads at different frame rate. c#2 is correct and provides a workaround, how to run reveal-keyframes-2 om main thread. There is not much we can do here. This is a nice case to consider while implementing devtools support (https://bugs.chromium.org/p/chromium/issues/detail?id=230229)
,
Nov 23 2016
Also, we have an idea to accelerate animation of CSS width/height properties when possible. https://bugs.chromium.org/p/chromium/issues/detail?id=568257
,
Jul 12 2017
I'd like to resurrect this issue to get clarification on animating width/height versus clip-path. I can understand how the former might be a trickier matter, since it may entail reflowing the document (although not in the particular example linked above), but I'm less clear on why it's problematic to animate clip-path. Why can't the clip-path animation be run on the same thread as the transform animation? |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ligim...@chromium.org
, Oct 19 2016Components: -Blink Blink>Animation
Labels: pre-stable-54.0.2840.59 Needs-Bisect M-54