html - 浏览器是否渲染不在视口(viewport)内的 Canvas 元素？

Question

我有一个页面正在进行非常繁重(中等重量)的 canvas 操作。为了迎合移动设备和旧计算机上的用户，我想我可以实现一种机制来检查 Canvas 元素是否确实可见，并决定是否必须进行持续计算和 Canvas 更新(以 30fps 运行的动画) .

这工作正常，但在使用 Chrome 开发工具进行性能测试时，我注意到即使我禁用可见性检查并让事情一直呈现，相关函数的 CPU 使用率也会下降很多canvas 元素的任何部分都不可见(尽管理论上它仍应执行相同的任务)。所以:至少在我运行 Chrome 17 的计算机上，如果我检查元素的实际可见性并没有真正的区别。

长话短说:我是否需要这样做，或者浏览器是否足够聪明，可以在不告诉它们的情况下处理这种情况(并且我可以保存可见性检查)？

---

编辑:

所以我对这个主题做了一些“研究”并构建了 this fiddle.

实际情况是它仅以每秒 30 帧的速度生成噪声。不太赏心悦目，但是，好吧……上半部分只是一个普通的 div 来挡住视口(viewport)。当我向下滚动并在视口(viewport)中显示 canvas 元素时，CPU 使用率告诉我它占用了大约 40%，因此显然浏览器在这里确实有很多工作要做。当我向上滚动以便在我的视口(viewport)中只有栗色的 div 并分析 CPU 使用率时，它下降到 10% 左右。当我向下滚动时:使用率再次上升。

因此，当我像这个 modified fiddle 那样实现可见性检查时，我确实看到了 CPU 使用率的增加(说实话是很小的)而不是下降(因为它有检查 Canvas 是否在视口(viewport)内的额外任务)。

所以我仍然想知道这是否是我不知道的某些副作用(或者我在分析时犯了一些重大错误)或者我是否可以期望浏览器足够智能来处理这种情况？

如果有人能阐明这一点，我将不胜感激!

Answer 1

我认为您对逻辑 是否正在运行和呈现 是否正在发生感到困惑。许多浏览器现在对它们的 Canvas 进行硬件加速，因此所有渲染都在 GPU 上进行，因此实际的像素推送无论如何都不占用 CPU 时间。但是，您的 tick 函数具有在 CPU 上生成随机噪声的重要代码。所以你真正关心的只是 tick 函数是否在运行。如果 Canvas 在屏幕外，它肯定不会被渲染到显示器上(它是不可见的)。至于 Canvas 绘制调用，可能取决于浏览器。它可以将所有绘制调用渲染到屏幕外 Canvas ，以防您突然将其滚动回 View ，或者它可以将所有绘制调用排队，并且在您将 Canvas 滚动到 View 之前实际上不对它们执行任何操作。我不确定每个浏览器在那里做什么。

但是，您不应使用 setInterval 或 setTimeout 为 Canvas 设置动画。使用新的 requestAnimationFrame应用程序接口(interface)。浏览器不知道您在计时器调用中做了什么，因此将始终调用计时器。另一方面，requestAnimationFrame 是专门为视觉对象设计的，因此如果 Canvas 或页面不可见，浏览器有机会不调用 tick 函数，或降低调用频率。

至于浏览器实际上如何处理它，我不确定。但是，您绝对应该更喜欢它，因为 future 的浏览器可能能够以它们无法优化 setInterval 或 setTimeout 的方式更好地优化 requestAnimationFrame。我认为如果页面不可见，现代浏览器也会将普通计时器降低到 1 Hz，但浏览器优化 requestAnimationFrame 肯定容易得多，另外一些浏览器还可以让您进行垂直同步和其他好处

所以我不确定 requestAnimationFrame 是否意味着在 Canvas 滚出 View 时不会调用您的 tick 函数。所以我建议使用 both requestAnimationFrame 和现有的可见性检查。这应该可以保证您获得最高效的渲染。