小文件和大文件上的 HTML5 画布性能答案

【问题标题】：HTML5 canvas performance on small vs. large files小文件和大文件上的 HTML5 画布性能
【发布时间】：2011-12-18 06:10:20
【问题描述】：

我似乎在使用基于页面内存大小的 HTML5 画布时体验到不同的性能......也许是加载的图像（屏幕外画布）的数量。如何最好地定位性能问题的根源？或者有谁知道在加载大量数据时是否确实存在性能问题，即使不是一次全部使用？

Here's an example of good performance.我有一张比较简单的地图。它在 700 到 800 KB 之间。您可以拖动以相对平滑地滚动此地图。

There's another file（由于它的尺寸很大，您可能不想看）。

它大约 16 MB，包含几十个，可能在一百个图像/画布上。它绘制了一个较小的视图，因此它应该走得更快。但事实并非如此。与简单的演示相比，许多地图严重滞后。

我可以尝试检测代码以开始计时，但我之前没有在 JavaScript 中做过，并且可以使用一些帮助。如果有更简单的方法来定位性能问题的根源，我会很感兴趣。

【问题讨论】：

【解决方案1】：

在 Google Chrome 和 Chromium 中，您可以打开开发者工具（tools->developer tools），然后点击“Profiles”。按下底部的圆圈，让画布重绘，然后再次单击圆圈。这会为您提供一个配置文件，显示在哪里花费了多少时间。

【讨论】：

谢谢！这很有帮助。事实上，花费大部分时间的函数是在画布上绘制的函数。我需要对其进行更多调查，并且可能会有后续问题。我会将调用该函数的次数与简单示例调用它的次数进行比较。如果它少（如预期），我可能会有后续问题。
我决定将我当前的后续问题作为一个单独的问题发布到 stackoverflow.com/questions/7965592/…，所以我会接受这个问题的答案。
我还发现 chrome://tracing 提供了一些信息，但就我的经验水平而言并不是很有用。我在后续问题中发布了一些结果，但我不知道该怎么做。

【解决方案2】：

我一直在处理一些复杂的画布内容，其中渲染性能对我很重要。

我在 jsperf 中编写了一些测试用例，得出的结论是，根据经验，源屏幕外画布不应超过 65536 像素。

我还没有得出关于为什么会这样的结论，但是在处理大型 source 画布时，可能必须更改数据结构或数据类型。

putImageData 显示了类似的结果。
目标画布大小似乎并不重要。

【讨论】：