我们如何将浏览器视频渲染器的单帧耗时降低 80%
一段 30 秒的产品宣传片——在 1920×1080 分辨率下共 1,050 帧——当时的渲染速度约为每秒一帧。而这台机器在运行现代游戏时毫无压力。同样的任务在我们的无头渲染服务器上则需要 10 分钟。
本文记录了我们要如何发现四个截然不同的问题，在一次代码提交中修复了它们，并将每帧的场景中位数耗时从约 0.5–1.0 秒降低到约 90–165 毫秒——同时提供了像素级的证据，证明输出结果未发生变化。好吧，几乎没变：验证过程还捕获了一个真正的错误。
60 秒了解渲染器
我们的引擎通过将每一帧绘制到画布上，然后将位图提供给 WebCodecs VideoEncoder（MP4 格式中的 H.264）来渲染视频。图层是文档对象模型元素——文本、图像、具有真实层叠样式表的形状——因此栅格化图层意味着调用来自 modern-screenshot 的 domToCanvas，它将元素的子树序列化为可缩放矢量图形 <foreignObject> 并对其进行栅格化。效果图层还会经过 WebGL 合成器进行模糊、失真和层叠样式表滤镜处理。完全相同的代码包在两个地方运行：用于预览和本地导出的浏览器标签页，以及用于应用程序接口渲染的我们在 Railway 工作节点上的无头 Chromium。
这种架构使得“每秒一帧”的表现显得尤为尴尬：每个图层已经渲染为平面位图。每帧的工作量应该只是少量的画布绘制和一次编码调用。
测量方法
我们没有对整个渲染过程进行性能分析——那个数字是一个总和，而总和会掩盖一切。我们在每帧流水线（文档对象模型捕获、效果合成、叠加层处理、编码）的每个阶段周围设置了计时器，并取了每个场景的中位数，因为我们的四个场景使用了非常不同的图层。总体中位数是每帧约 0.9 秒的串行工作。细分数据指向了四个不同子系统中的四个独立问题。
发现 1：预览叠加层被计入导出成本
预览用户界面显示后期效果叠加层画布，以便您可以单独查看效果对图层的影响。这项工作由一个 EffectOverlayManager 负责——其 process() 方法在每个导出的帧上也运行，尽管导出过程根本没有用户界面。代价：每帧纯浪费 60–260 毫秒，具体取决于场景。
修复方法是添加一个标志：captureFrame（导出路径）现在会禁用叠加层处理。免费的收益，零风险。
发现 2：WebGL 上下文频繁重建
效果图层以其填充后的边界框大小进行合成。旧代码在大小改变时会执行以下操作：
effectCompositor?.destroy();
effectCompositor = new WebGLEffectCompositor(padded.width, padded.height);
销毁合成器意味着丢失图形库上下文（WEBGL_lose_context）并在下一帧重新编译所有着色器。动画图层的边界框不断变化，因此我们在渲染过程中反复付出完整的上下文 teardown 代价。修复方法是建立一个微小的最近最少使用池，以精确的渲染尺寸为键，上限为四个实例——足以覆盖场景交替使用的少数几种尺寸，足够小以至于一个
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
