HTML转Canvas性能问题，如何入手？

Question

我一直在进行一个实验，将HTML渲染成画布图像，通过javascript从加载的DOM中读取所有必要的信息。由于画布缺少许多标准的CSS部分，特别是在文本格式方面，需要进行大量的解决方法和性能密集型的过程（例如letter-spacing）。意图并不是制作一个完美的HTML渲染器，因为这根本不可能，而是尽可能精确地尝试。

对于示例页面，Google Chrome通常比FF加载得快得多。然而，对于一些页面（通常是较大的页面），Chrome完全会冻结，而Firefox则可以正常加载它们。现在，我一直在试图找到问题出在哪里，但是没有什么好运气，因为它没有在Chrome中输出任何内容。

Chrome是否有某些限制，限制了在某个时间段内可以执行多少个画布绘制，或者页面可以使用多少系统资源？如果我无法从页面获得任何反馈（因为它只是挂起），如何开始解决瓶颈？

示例（它应该在页面顶部呈现一个画布图像，看起来与实际的HTML页面更或多或少相同。您可以通过单击它来切换画布图像（显示/隐藏）。如果浏览器中有未保存的工作，请不要打开它们，因为它们也可能会挂起。）： 简单测试，在FF / Chrome中正常工作 另一个简单的测试，在FF / Chrome中正常工作 完整页面，在FF / Chrome中正常工作 完整页面，仅适用于FF < 4，Chrome冻结 它们都使用相同的js，可以在这里找到： 这里。

我不是在寻找一个飞快的脚本，因为随着这种仿真类型渲染图像，我认为甚至不能完成。只是试图找到使它可能稍微更有效率的方法，而不失去其当前的功能。

- Niklas

---

嗨 - 我会检查代码是否导致了无限循环或其他问题，因为http://hertzen.com/experiments/html2canvas/tests/palmtrees/ 也会使FF4卡死。 - Kinlan

最后一个例子会导致我的FF4（4.0.1）崩溃，首先是无响应脚本警报，然后我必须杀死进程并重新启动。而且页面尝试在Chrome中加载，但从未成功。不过我仍然可以继续使用Chrome。但是FF不行（正如我所猜测的那样）。 - Jared Farrish

所以我猜这不仅是Chrome的问题。如果这是一个无限循环，那么早期版本的FF也应该会崩溃？ - Niklas

早期版本的FF有画布吗？ - Jared Farrish

在Firebug中尝试使用一些断点，看看问题从哪里开始。FF4具有与早期版本不同的基础JS引擎，这可能导致它出现问题。 - Jared Farrish

自从1.5版本以来，Canvas已经在FF中存在。 - Jared Farrish

Answer 1

从哪里开始？

分解它。

使用同样的示例，将你所做的内容（渲染代码）减少一半。还是不起作用吗？再次减少一半，以此类推。它起作用了吗？把你拿走的一半放回去。

也就是说，摆脱所有尝试的文本呈现，或所有边框/填充代码。只是注释掉它。然后，它是否有效？

或者尝试仅注释掉第199行的ctx.drawImage（img，x，y）;而不是其他任何内容。然后是否有效？

如果你很幸运，你就能确定Chrome正在某个关键点花费大量时间。

- Simon Sarris

---

谢谢，加入一些警报帮助我确定它停止响应的位置。 - Niklas

Answer 2

你尝试过使用Chrome内置的性能分析器吗？

- user172783

---

不，现在可能可以使用了，因为它不再卡住了。但在此之前，无法使用，因为页面根本无法加载。 - Niklas

Answer 3

问题似乎出在CSS属性background-repeat上，特别是repeat-x。将其注释掉即可。

for(bgx=(x+background_position_left);bgx<=w;){
                            drawImage(image,bgx,(y+background_position_top));
                            bgx = bgx+image.width;
                        }

至少对于Chrome修复了这个问题，根据Kinlan的建议，很可能是一个无限循环的问题，但为什么它只会在较新版本的Firefox和Chrome上卡住，我需要更详细地研究一下（很可能是因为图像宽度尚不可用或类似的原因）。

- Niklas