主要线程中卡住的Chrome浏览器合成器驱动的动画 [英] Google Chrome compositor-driven animation affected by jam in main thread

问题描述

https： //jsfiddle.net/1rk65nxj/

我使用CSS动画为 .spinner 元素设置动画效果。元素本身使用 will-change：transform 和 translateZ（0）作为后备提升到自己的合成层。

现在，我阻塞主线程执行如下操作：

  var i = 999999; 
 
 while（i> 0）{
 i--; 
} 
  

由于CSS动画是合成器驱动的页面更新，我预计主线程会阻塞现在，奇怪的是，如果我将元素的位置从相对位置改变为绝对位置，那么主线程阻塞并不会阻止微调器，但它确实会停止。 停止微调。

任何解释为什么 position：absolute 会使动画合成器驱动，<$ c $在Google Chrome 48.0.2564.116（64位），Mac OS X El Capitan上， p>

解决方案

这似乎是Chrome中的一个错误。我已在此提交： https://bugs.chromium.org/ p / chromium / issues / detail？id = 592803

Here is the fiddle showing the puzzler:

https://jsfiddle.net/1rk65nxj/

I am animating this .spinner element using CSS animation. The element itself is promoted to its own compositing layer using will-change: transform and translateZ(0) for fallback.

Now, i jam the main thread doing something like:

var i = 999999; 

while ( i > 0) {
    i--;
}

Since CSS animations are compositor-driven page updates, I expected the main thread jam not to halt the spinner but it does.

Now, the weird thing is, if I change the position of the element from relative to absolute, the main thread jam does not halt the spinner.

Any explanation on why position: absolute makes the animation compositor-driven and position: relative not?

On Google Chrome Version 48.0.2564.116 (64-bit), Mac OS X El Capitan.

解决方案

This appears to be a bug in Chrome. I've filed it here: https://bugs.chromium.org/p/chromium/issues/detail?id=592803

这篇关于主要线程中卡住的Chrome浏览器合成器驱动的动画的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！