在 Linux 上优化 WebKit 中的动画性能答案

【问题标题】：Optimizing animation performance in WebKit on Linux在 Linux 上优化 WebKit 中的动画性能
【发布时间】：2018-01-30 00:51:50
【问题描述】：

如何优化已编译的 WebKit 浏览器以充分利用 GPU？

背景

我和我的团队正致力于配置一个 Linux 机器 (CentOS) 以显示具有流畅的 CSS 驱动动画的全屏 HTML。该盒子具有足够的 GPU 和 CPU 能力，并且能够在 Chromium 中轻松播放这些动画。

但是，我们正在尝试使用纯 WebKit 来呈现这些动画，方法是在 Python 中使用 WebKitGTK+ 并从源代码将 WebKit 编译为一个简单的浏览器。

当前状态

在这两个“纯”webkit 应用程序中，动画比 Chromium 上的慢得多，这让我们摸不着头脑来回答两者之间究竟的不同之处。我们知道 Chromium 使用 Blink，WebKit 的一个分支，我们目前认为性能差异是由于 Chromium、Safari 和其他基于 WebKit 的浏览器都使用自己的图形组件，这些组件独立于 WebKit 和 Web Core 本身，根据我们阅读的内容。

如果我们可以自定义我们的 WebKit 构建以执行我们在 Chromium 中看到的规格的一半，那就太好了，但我们不确定从哪里开始。

我想知道...

我们关于单独图形组件的假设是否正确？
我们有哪些选项可以在像我们这样的“纯”WebKit 浏览器中优化 CSS 动画性能？

【问题讨论】：

那么为什么不在 Blink 中建立你的 fork 呢？什么 WebKit 版本？此外，尽管过去 2 天 jsperf.com 似乎已关闭，但当我将 Chrome (Mac) 升级到 64.0.xxxx 并运行基准测试时，HTML 呈现性能是 Chrome 在那里记录的最差的。也许 Blink 继承了 WebKit 的“坏”版本？
1.你的意思是我们的代码？ Chromium/Blink 没有满足我们需求的许可证。 2. 不确定我们是否在谈论同一件事。铬是我们的“好”比较。我们发现纯粹构建的 WebKit 的性能很差。
嗨，你如何编译 Webkit ？可能需要设置一些参数以更有效地使用您的拱门
不确定这是否有用。但是遇到了我想分享的一种情况。最近我们使用transform3d开发了使用大量动画的网页，动画在桌面的chrome和iphone 6plus的ios 11上运行良好。但是在 iphone.6 中的 ios10 上表现非常糟糕，并且页面曾经崩溃得非常糟糕。在经历了一系列优化过程和调试之后，我们发现创建的 transform3d 层在两种实现中都有不同的内存占用，这就是页面崩溃的原因。
..所以我们最终决定稍微改变一下动画，这样我们就可以减少一些 transform3d。我这么说的原因是 webkit 版本之间可能存在一些差异，所以你可以从那个角度看。还有一个思路是看GPU处理的帧大小在chromium和webkit上是不是一样。

标签： c++ css linux webkit gtk

【解决方案1】：

我不确定能否在您的项目中为您提供帮助，但我最近学到的一件事是我们可以通过将图形密集型 CSS 功能卸载到 GPU 来硬件加速它们以获得更好的浏览器渲染性能。

现在大多数现代浏览器都带有硬件加速功能。当他们看到 DOM 将从中受益时，他们将使用它。一个强有力的指标是 3D 转换。

假设您想将 DOM 放置在绝对位置并将其提升到父容器上方。取而代之的是，您实际上可以使用 -webkit-transform: translate3d(10px,10px,10px); 即使我们根本不为元素设置动画，它也会解析为 3D 渲染。即使您设置零值，它仍然会触发图形加速。

提示如果您看到任何闪烁，请尝试添加 -webkit-backface-visibility: hidden; 和 -webkit-perspective: 1000;

现在让我们谈谈 CSS 的基础知识

您应该知道，浏览器如何读取您的 CSS 选择器最重要的是，它们从 从右到左读取它们。这意味着在选择器中 @ 987654325@ 第一个解释是img[alt="test.png"]。第一部分也称为“键选择器”。

首先，ID 是最有效的，而通用性最少。因此，您可以重写 CSS 代码，用 ID 替换全局代码（当不需要时） 。

另一种降低浏览器速度的方法是预先添加 全局选择器。 (div#my-div) Chrome 在检查模式下默认执行的操作。 这会大大降低您的浏览器速度。

到目前为止，最糟糕的情况是后代选择器。即使是失败的选择器（当您的选择器不匹配任何内容时）也比 html body div ul li a { }

另外一件非常有用且干净的事情是 CSS3 选择器 (:last-child)。即使这些选择器可以帮助我们并使我们的生活更轻松，它们也会破坏您的浏览器。在小型应用程序中您可能看不到任何性能差异，但是当您在企业应用程序中引入它们时，您会注意到它们会减慢您的渲染速度。

总结一下。我刚刚告诉过你，用 ID 替换所有选择器并通过 ID 对每个元素应用样式将使你的应用程序超级快，但另一方面它会有点傻。这将非常难以维护并且也是非语义的。因此，您应该考虑用 ID 替换大多数选择器，但不要为了 高效的 CSS

而牺牲 语义/可维护性

你也可以检查一个有趣的测试here。

现在我想到了，我应该从 CSS 基础开始。哦，好吧，我希望我对你的项目有一点帮助。干杯

【讨论】：

谢谢，这是一个很好的观点，但我忘了提及。在我们的 CSS 中，我们尽可能使用 transform 属性来确保 GPU 的使用。如果已经支持非前缀属性，您认为 -webkit 前缀会有所不同吗？
@AdamGrant 可能不会。我过去从未经历过任何不同，我的大部分开发工作都是在 Chrome 上进行的。

【解决方案2】：

根据Guil Hernandez's article CSS 动画，变换和过渡不会自动 GPU 加速，而是从浏览器较慢的软件渲染引擎执行。那么究竟是什么迫使浏览器切换到 GPU 模式呢？许多浏览器通过某些 CSS 规则提供 GPU 加速。

例子：

.cube {
   -webkit-transform: translate3d(250px,250px,250px)
   rotate3d(250px,250px,250px,-120deg)
   scale3d(0.5, 0.5, 0.5);
}

【讨论】：