在css3实验中,我将10,000个小div元素从browser视口的顶部移动到底部。对于这个测试,我使用了两种不同的方法:
使用translate3D(x, y, z)
或translateZ(0)
中的top
属性即可实现
使用不使用硬件加速在Google Chrome上运行相当流畅。
如果我启用硬件加速,性能会变得更差。很糟糕的是,盒子甚至不再均匀地分布:
使用GPU/硬件加速:
没有GPU/硬件加速:
问题
为什么会这样呢?使用GPU不应该提高性能吗?
演示应用程序
https://www.timo-ernst.net/misc/hwtest/
来源
https://github.com/valnub/hwtest
我用于测试的硬件
更新 (2014-11-13):由于这个问题仍然吸引着人们的注意,我想指出这个问题本身似乎仍然存在,尽管在提供的现代硬件__上的演示中可能看不到前面提到的卡顿。较旧的设备可能仍会遇到性能问题。
*更新II (2021-02-17):问题仍然存在,但您必须根据使用的硬件增加演示中移动的盒子数量。我更改了演示应用程序的UI,以便您现在可以调整移动的框的数量,以便为您的特定硬件创建卡顿动画。为了重复这个问题,我建议创建足够多的盒子来查看启用了GPU/硬件加速的卡顿。然后在框中打勾,在没有加速的情况下再次运行测试。动画应该更流畅。
发布于 2015-06-25 10:14:55
添加null transform hack (translateZ(0)
)时动画变慢的原因是每个空3D变换都会创建一个新层。当这些层太多时,渲染性能会受到影响,因为浏览器需要向GPU发送大量纹理。
这个问题是在2013年苹果的主页上发现的,苹果滥用了null transform的黑客攻击。请参阅http://wesleyhales.com/blog/2013/10/26/Jank-Busting-Apples-Home-Page/
OP还正确地注意到了their comment中的解释:
当使用3D加速时,
移动几个大对象比移动许多小项目性能更好,因为所有3D加速的层都必须传输到图形处理器并返回。因此,即使图形处理器做得很好,许多对象的传输也可能是一个问题,因此使用图形处理器加速可能不值得。
发布于 2012-04-13 08:22:16
我总是补充说:
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
使用3d变换时。甚至是“假的”3D变换。经验告诉我,这两条线总是能提高性能,特别是在iPad上,在Chrome上也是如此。
我在你的例子上做了测试,据我所知,它是有效的。
至于你问题的“为什么”部分..。我不知道。3D变换是一个年轻的标准,因此实现起来并不稳定。这就是为什么它是一个前缀属性:用于beta测试。有人可以填写错误报告或问题,并让团队进行调查。
根据2013年8月19日编辑
有关于这个答案的常规活动,我只是浪费了一个小时才发现IE10也需要这个。所以别忘了:
backface-visibility: hidden;
perspective: 1000;
发布于 2012-04-12 06:41:03
有意思的。我尝试过在about:flags
中使用一些选项,特别是这些选项:
所有页面上的GPU合成在所有页面上使用GPU加速合成,而不仅仅是那些包含GPU加速层的页面。
当启用合成时,GPU加速绘图启用页面内容的GPU加速绘制。
图形处理器加速的Canvas 2D通过使用图形处理器硬件进行渲染,实现了具有2D上下文的画布标签的更高性能。
启用了这些,尝试了一下,但在启用tickbox的情况下失败了(就像你做的那样)。但后来我注意到了另一种选择:
当硬件加速激活时,
FPS计数器以每秒帧数为单位显示页面的实际帧率。
考虑到标志描述中的突出显示,我推测硬件加速实际上对我来说是开启的,因为我看到FPS计数器打开了上面的选项!
TL;DR:最终,硬件加速是用户的偏好;用虚拟translateZ(0)
强制它将引入冗余的处理开销,从而造成性能下降的外观。
https://stackoverflow.com/questions/10014461
复制相似问题