手动使 Chrome 中的复合层无效

如何解决手动使 Chrome 中的复合层无效

背景

我正在开发一个内置 HTML（不是 WebGL/Canvas）的网络应用程序，其中包括用于平移和缩放页面内容的 2d 视口控件。也许像 Figma 这样的东西，但完全用 DOM 渲染，这是一个硬性技术要求。

为了实现视口功能，我广泛使用 CSS transform 来支持所有偏移和动画，以尽可能减少渲染合成更改所需的工作。我的应用程序的“画布”包含许多可以由用户移动和调整大小的离散项目，类似于任何典型的操作系统窗口管理器。这些“小部件”可能包含它们自己的可滚动内容。

例如，在平移 50 像素、25 像素并缩放至 1.5 倍之后，对于在 (20,100) 处具有小部件的特定“画布”，DOM 和变换值可能如下所示：

<div id="canvas" style="transform: scale(1.5,1.5) translate(50px,25px)">
  <div id="widget-1" style="transform: translate(20px,100px)" />
</div>

经过大量实验后，我发现在多个浏览器中呈现这些项目的最有效方法是通过将 will-change: transform 应用于最外层元素来将每个单独的“小部件”提升到其自己的层。这会产生相当合理的帧速率，即使在平移和缩放时帧中有大量内容也是如此。

Webkit 不当行为

然而，有一个问题 - 在基于 Webkit 的浏览器上，缩放时（通过 scale 转换在根画布元素上的 CSS 应用），小部件的内容不会重新光栅化以适应新的比例值。在大于 1x 的缩放比例下，这会产生明显的模糊。尤其是带有文字的图片，基本上是不可读的。

上图是一个图像小部件和另一个 1 倍（原生）比例的 DOM 文本小部件。

现在，以 2 倍比例缩放（您将无法在这篇文章中内联分辨出差异，但您可以在全分辨率下看到它）。请注意，图像和以前一样难以辨认，文本也很模糊。

要实时重现此问题，请参阅 this CodeSandbox（不选中“动画”）。

旁注：这只发生在 Chrome、Safari 和 Edge 上 - 所以它看起来像是 Webkit 渲染行为的产物。 Firefox 实际上可以很好地扩展所有内容，并且启动速度更快。

然而，这种方法的性能是可取的。在尝试了其他一些分层配置之后，我决定最好的方法是在缩放更改动画完成后尝试强制浏览器重新光栅化小部件。

黑客

预期目标是允许旧的光栅化纹理在缩放动画期间保持不变以使其尽可能平滑（因此当视口放大/缩小时会出现上面看到的模糊），但触发重新动画完成后以最终比例进行光栅化 - 重新绘制所有小部件，同时考虑当前比例，使其内容即使在 2 倍缩放时也清晰易读。

为了纠正这个问题，我实现了一种“hack”的感觉：在每个缩放动画结束后，我将所有小部件上的 will-change 从 transform 切换到 {{ 1}} 为 1 帧，然后再返回：

initial

这确实有效。现在，当我放大到 2 倍时，图像文本清晰易读，DOM 文本清晰明了：

（在我的应用中，您甚至可以看到缩放动画“稳定”和文本“弹出”为高分辨率的那一刻。）

但是，如果我理解正确的话，上面的代码实际上是在强制浏览器为每个小部件处理 1 帧的复合层，然后重新创建它。虽然性能在实践中似乎可以接受，但我更愿意让浏览器使其已经构建的层无效。

问题

所以，抛开所有这些上下文，问题很简单：有没有办法手动触发复合层的失效而不破坏它？也许是一个神奇的 CSS 咒语？

我也对图层分组方面的替代方法持开放态度，这些方法可能会在不损害渲染性能的情况下改善行为。

我尝试过的其他东西

我在创建 reproduction CodeSandbox 时注意到的一件事是，如果我将 const rerasterize = () => { requestAnimationFrame(() => { element.style.willChange = 'initial'; requestAnimationFrame(() => { element.style.willChange = 'transform'; }); }); }; 属性添加到“画布”元素（正在转换以实现视口更改），即使小部件被合成在不同的图层中，它似乎修复了模糊性。您可以通过在演示中选中“动画”来看到这一点。但是，我的动画目前是通过 JS 完成的，因此在此基础上添加辅助 CSS 过渡似乎不是一个好计划。

我尝试完全撕掉 JS 动画并仅依赖于 transition，但令人惊讶的是，这似乎没有帮助。平移和缩放感觉明显不稳定（其中一些可能归结为原生缓动感觉不如基于 JS 弹簧的缓动自然），但更令人担忧的是 GPU 内存使用和丢帧明显比没有 transition 更糟糕 - 这导致我相信 transition 可能会在 GPU 上为我的用例带来比我真正想要的更多的工作（可能在动画期间经常使图层无效，我希望它们在过渡结束之前保持完整）。