HTML 到画布的性能问题，从哪里开始？
我一直在进行一项实验，通过让 javascript 从加载的 DOM 中读取所有必要的信息，将 HTML 渲染到画布图像中。由于 canvas 缺乏 CSS 的许多标准部分，尤其是在文本格式方面，因此需要完成大量工作和性能密集型流程（其中之一是letter-spacing）。我们的目的是并且永远不会是制作一个万无一失的 HTML 渲染器，因为它根本不可能，而是尝试尽可能准确。
对于示例页面，Google Chrome 的加载速度通常比 FF 快得多。然而，对于某些页面（通常是较大的页面），Chrome 完全冻结，而 Firefox 可以正常加载它们。现在，我一直在试图找出到底哪里出了问题，但运气不佳，因为它最终没有在 Chrome 中输出任何内容。
Chrome 是否对在一定时间范围内可以执行的画布绘制次数或页面可以使用多少系统资源有一定的限制？如果我根本无法从页面获得任何反馈（因为它挂起），我该如何开始解决瓶颈？
示例（它应该做的是在页面顶部渲染一个画布图像，该图像看起来应该与实际的 HTML 页面或多或少相同。您可以通过单击画布图像（显示/隐藏）来切换它。请不要如果您的浏览器中有未保存的工作，请打开它们，因为它最终也可能会挂起它们。）：
它们都使用相同的js，可以在这里找到。
我并不是在寻找一个速度极快的脚本，就像渲染图像的模拟类型一样，我认为它甚至无法完成。只是试图找到一种方法，使其稍微提高效率，同时又不会失去任何当前的功能。
I have been working on an experiment to render HTML into a canvas image, by having javascript read all the necessary information from the loaded DOM. As canvas lacks many of the standard parts of CSS, especially when it comes to text formatting, a lot of work arounds and performance intense processes need to be done (letter-spacing for one). The intent is and never will be to make a fool proof HTML renderer, as it simply won't be possible, but instead try and make as accurate as it can be.
For the sample pages, Google Chrome usually loads them significantly faster than FF. However, for some pages (usually the bigger ones), Chrome completely freezes, where as Firefox loads them fine. Now, I have been trying to pinpoint where exactly things go haywire, but haven't had much luck as it doesn't end up outputting anything in Chrome.
Does Chrome have some limit of how many canvas draws can be performed within a certain time span, or how much system resources a page can use? How can I start untangling the bottleneck if I can't get any sort of feedback from the page at all (as it just hangs up)?
Examples (what it should do, is render a canvas image on top of the page, which should look more or less same than the actual HTML page. You can toggle the canvas image (show/hide) by clicking it. Please don't open them either if you got unsaved work in your browsers, as it may end up hanging them as well.):
simple test, works fine in FF/Chrome
another simple test, works fine in FF/Chrome
Complete page, works fine in FF/Chrome
Complete page, only works in FF < 4, Chrome freezes
They all use the same js which can be found here.
I am not looking for a blazing fast script, as with the type of emulation this renders the images, I don't think it could even be done. Simply trying to find ways to make it perhaps slightly more efficient, without losing any of its current functionality.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否尝试过使用 Chrome 的内置性能分析器？
Have you tried using Chrome's built-in performance profiler?
问题似乎出在 css 属性
background-repeat上，特别是repeat-x上。注释掉至少修复了 chrome 的问题，并且看到它很可能是 Kinlan 提出的无限循环，但为什么它只在较新版本的 FF 和 chrome 上卡住，这是我需要更详细地查看的内容（很可能还没有可用的 image.width 或类似的东西）。
The problem appeared to be with the css attribute
background-repeat, and specificallyrepeat-x. Commenting outFixed the issue at least for chrome, and looking at that it most likely was an endless loop as Kinlan proposed, but why exactly it gets stuck only on newer versions of FF and chrome is something I'll need to look more in detail (most likely not having the image.width available yet, or something similar).
从哪里开始？
分解它。
使用相同的示例，并将您的操作量（渲染代码）减少一半。还不行吗？又减半，等等。有效吗？把取出来的一半放回去。
就像这样，摆脱所有尝试的文本渲染，或所有边框/填充代码。注释掉就可以了那行得通吗？
或者尝试仅注释掉第 199 行的 ctx.drawImage(img,x,y); ，而不做其他任何事情。那行得通吗？
如果幸运的话，您将能够确定 Chrome 花费大量时间做某事的关键点。
Where to begin?
Break it down.
Use the same example and cut how much you do it it (your rendering code) in half. Does it still not work? In half again, etc. Did it work? Put back half of what you took out.
As in, get rid of all attempted text rendering, or all border/padding code. Just comment it out. Does it work then?
Or try just commenting out
ctx.drawImage(img,x,y);on line 199 and nothing else. Does it work then?If you're lucky you'll be able to determine a critical point where Chrome is spending a lot of time doing something.