Fatal编程技术网
  • css/
  • 为什么在CSS3中启用硬件加速会降低性能？

为什么在CSS3中启用硬件加速会降低性能？

css performance

为什么在CSS3中启用硬件加速会降低性能？,css,performance,css-transitions,css-transforms,Css,Performance,Css Transitions,Css Transforms,在css3实验中，我将10000个小div元素从浏览器视口的顶部移动到底部。对于本测试，我使用了两种不同的方法： 使用translate3D（x，y，z）或translateZ（0） 通过简单地调整css中的top属性，不需要GPU加速 使用NO硬件加速在Google Chrome上运行相当平稳 如果启用硬件加速，性能会变得更差。太糟糕了，箱子甚至都没有均匀分布： 使用GPU/硬件加速： 没有GPU/硬件加速： 问题: 为什么会这样？使用GPU不应该提高性能吗 演示应用程序 来源 我

在css3实验中，我将10000个小div元素从浏览器视口的顶部移动到底部。对于本测试，我使用了两种不同的方法：

  • 使用
    translate3D（x，y，z）
    或
    translateZ（0）
  • 通过简单地调整css中的
    top
    属性，不需要GPU加速
    • 使用NO硬件加速在Google Chrome上运行相当平稳

    如果启用硬件加速，性能会变得更差。太糟糕了，箱子甚至都没有均匀分布：

    使用GPU/硬件加速：
    没有GPU/硬件加速：
    问题: 为什么会这样？使用GPU不应该提高性能吗

    演示应用程序

    来源

    我的硬件用于测试
    • 苹果Macbook Pro 15英寸2015款
    • CPU 2.8 GHz Intel Core i7
    • 16GB内存
    • 马科斯大苏尔11.2
    更新（2014-11-13）：由于这个问题仍然吸引着人们的注意，我想指出问题本身似乎仍然存在，尽管在现代硬件上提供的演示中提到的口吃可能不再可见。旧设备可能仍然会出现性能问题

    *更新二（2021-02-17）：问题仍然存在，但您必须根据所使用的硬件增加演示中移动的框的数量。我更改了演示应用程序的UI，因此您现在可以调整移动的框的数量，以便为您的特定硬件创建口吃动画。要复制此问题，我建议创建足够的框来查看口吃在启用GPU/硬件加速的情况下。然后勾选该框，在不加速的情况下再次运行测试。动画应该更平滑。

    检查chrome://flags 用铬，上面写着

    “当启用线程合成时，在合成线程上运行加速的CSS动画。但是，即使没有合成器线程，使用加速的CSS动画也可能会提高性能。”

    有趣。我尝试过在
    关于：标志
    中使用一些选项，特别是以下选项：
    
所有页面上的GPU合成在所有页面上使用GPU加速合成
页面，而不仅仅是那些包含GPU加速层的页面
    
GPU加速绘图启用页面的GPU加速绘图
启用合成时的内容
    
GPU加速画布2D实现更高性能的画布标签
使用图形处理器单元（GPU）渲染2D上下文
硬件
    
启用了这些，尝试了它，但在启用勾选框的情况下失败了（就像您所做的那样）。但随后我注意到了另一个选项：
    
FPS计数器显示页面的实际帧速率，单位为每秒帧数，
当硬件加速处于活动状态时
    
鉴于标志描述中的突出部分，我推测硬件加速实际上对我来说是启用的，即使没有勾选复选框，因为我看到FPS计数器启用了上述选项
    
TL；DR:硬件加速最终是用户的一种偏好；使用dummy
    translateZ（0）
    强制硬件加速将引入冗余的处理开销，从而导致性能降低。
    我始终添加：
    

    -webkit-backface-visibility: hidden;
-webkit-perspective: 1000;

    
当使用3d转换时。即使是“假”3d转换。经验告诉我，这两条线总能提高性能，尤其是在iPad上，但在Chrome上
    
我对你的例子进行了测试，据我所知，它是有效的
    
至于你问题的“为什么”部分…我不知道。3D转换是一个年轻的标准，所以实现是不稳定的。这就是为什么它是一个前缀属性：用于测试。有人可以填写错误报告或问题，并让团队调查
    
每2013年8月19日编辑一次：
    
在这个答案上有规律的活动，我花了一个小时才发现IE10也需要这个。
所以别忘了：
    

    backface-visibility: hidden;
perspective: 1000;

    

    我的经验是，GPU对于所有类型的图形通常不是更快。对于非常“基本”的图形，它们可能会更慢
    
如果旋转图像，可能会得到不同的结果-这是GPU擅长的事情
    

    也认为TrimeLez（0）是一个3维运算，而上或左变化是2维运算
     < P>我看到你们两个演示，我想我知道你们混淆的原因：
    

  • 动画元素不使用左侧或顶部来更改位置，请尝试使用-webkit变换
    • 

  • 所有子元素都需要启用硬件加速，例如使用translateZ（）或translate3D
    • 

  • FPS衡量动画流畅性，你的演示FPS平均只有20 FPS
    • 

    以上仅是个人意见，谢谢！
    添加（
    translateZ（0）
    ）时动画速度较慢的原因是每个空3D变换都会创建一个新层。当这些层太多时，渲染性能会受到影响，因为浏览器需要向GPU发送大量纹理
    
2013年，苹果的主页上发现了这个问题，滥用了空转换黑客。请参阅
    
OP也正确地注意到了以下方面的解释：
    
在使用3D加速时，移动几个大对象比移动很多小项目更有效，因为所有3D加速层都必须传输到GPU并返回。因此，即使GPU做得很好，许多对象的传输可能是一个问题，因此使用GPU加速可能不值得
    

    真正的问题是，为什么一些浏览器希望作者使用诸如“null”转换之类的愚蠢的黑客手段来激活硬件加速。Firefox尽可能地遵从GPU，而IE则选择加速所有的事情！但这里有一个有趣的问题从未出现过