解释 Chrome 开发工具中的丢帧答案

【问题标题】：Interpreting Dropped Frame In Chrome Dev Tools解释 Chrome 开发工具中的丢帧
【发布时间】：2021-06-27 07:43:00
【问题描述】：

我正在寻找有关在 Chrome 开发工具显示丢帧时如何解释它的信息。官方文档似乎没有涵盖这个或关于请求动画帧的 Udacity 课程。

我有一个 webGL 项目（使用 Three.js），我在制作动画时在 chrome 开发工具中看到以下内容 - 我正在使用 requestAnimationFrame。

明确地说，我不是在问如何修复我的代码，或者我的代码有什么问题。我正在寻求帮助以理解这告诉我的内容，代码无关紧要。

如果有人可以建议...

从上面的屏幕截图中，您可以看到它需要 15.7 毫秒，但警告有丢帧。如果我点击任务似乎需要 12 毫秒，那么额外的 3.7 毫秒来自哪里？由于我的功能都包含在“任务”部分中，我该如何找到？
在 ref 15.7ms 之前看到的绿色 1.0ms 是一帧吗？ - 这是否意味着我正在触发 requestAnimationFrame 但什么也不做？由于开发工具中没有显示任何内容，我怎样才能找出触发它的原因？

编辑。这是我能得到的一个更极端的例子，你可以看到它是同样的事情，我的任务实际上花了 9 毫秒，但它说帧是 82 毫秒！

【问题讨论】：

我记得几周前在谷歌上搜索过，偶然发现了与视频相关的结果。这个“掉帧”的事情今天再次让我感到困惑，所以我很高兴您在 SO 上提出这个问题，并希望 Google 团队的某个人能够阅读/回答它，或者编写适当的文档。但我相信“掉帧”并不是一件“坏事”。它甚至存在于最简单和最高效的动画中。就像一滴颜料掉在了屏幕上。我也相信 3.7 毫秒是 GPU 和合成器在屏幕上生成结果的时间。不知道 2。
感谢您的评论，我找不到关于此的任何体面的信息，所以如果任何视频有任何远程有用的东西，如果您能链接到它们会很棒。

标签： javascript google-chrome-devtools

【解决方案1】：

我不是谷歌的，甚至不是 DevTools 方面的专家，只是在 Chrome DevTools 中看了几行代码就过去了。

掉帧有几个原因，您可以在FrameDropReason查看。

但要了解丢帧的原因是什么，除了阅读分析 JSON 之外，我没有找到更好的方法，您可能会发现类似这样的内容：

{"args":{"data":{"compositeFailed":8192,"unsupportedProperties":["background-color"]}},"cat":"blink.animations,devtools.timeline,benchmark,rail","id2":{"local":"0x3b08a0fb80"},"name":"Animation","ph":"n","pid":23024,"scope":"blink.animations,devtools.timeline,benchmark,rail","tid":259,"ts":71014192568},

基本上说由于不支持的 CSS 问题，合成器丢弃了帧。有关合成器失败原因的更多详细信息here。

查看this issue 也很好，它跟踪了Dropped Frame 的添加。

同样，我不完全确定，只是一些提示供您研究。

【讨论】：

感谢您的评论，我对此一无所知。不幸的是，当我查看 JSON 并搜索compositeFailed 我得到.. {"args":{"data":{"compositeFailed":0}},"cat":"blink.animations,devtools.timeline,benchmark,rail ","id2":{"local":"0xe9a65653d10"},"name":"Animation","ph":"n","pid":688,"scope":"blink.animations,devtools.timeline ,benchmark,rail","tid":11828,"ts":329342225927}，这仍然不能告诉我太多（我不认为）
嘿，我刚刚更新了我的答案，提供了一个指向 Composite 失败原因的链接。基本上，您的compositeFailed: 0 日志显示no composite failed，因此您可能需要搜索其他compositeFailed，直到找到一个不为零的。

【解决方案2】：

这只是我个人的解释。

掉帧

即使是非常简单的动画也可能发生“丢帧”，但与我在上面的评论中所写的相反，它与实际呈现在屏幕上的帧不对应。

如果您创建一个非常简单的 Web 动画，如 opacity: [0, 1]，通过 CSS 或 JS 创建，并通过 Chrome v90 中的相应面板记录其性能，您应该会看到 98% 的帧是绿色的，2% 的帧是红色的（丢帧）。请注意，绿色和红色帧的持续时间可能更长，有时甚至少于 16.67 毫秒。

另外请注意，我相信在 Chrome v89 中报告了更多此类动画的红框。

动画任务后的 3.7 毫秒

这个时间似乎被图形处理单元用来使合成工作，如动画任务之后的（绿色，~1ms）GPU任务所示。不过还有 2.7 毫秒没有任何解释。

Chrome DevTools 似乎不是 100% 可靠的。可能是 GPU 和 CPU 之间的延迟，或者缺少信息。如果你录制一个不到 6 秒的简单动画，有时根本没有记录任何信息！但我相信衡量动画性能一直很困难，Chrome 正在尝试在其最新版本中对其进行改进。

动画前 1 毫秒

我认为这是浏览器在开始新的渲染周期之前运行强制任务所花费的时间。

总之，术语“帧”和“fps”（每秒帧数）的使用方式似乎让人难以理解。

【讨论】：