HTML到画布的性能问题,从哪里开始？

Question

我一直致力于通过让javascript从加载的DOM中读取所有必要信息,将HTML呈现到画布图像中的实验.由于canvas缺少CSS的许多标准部分,特别是在文本格式化方面,需要完成大量的工作和性能密集的过程(例如letter-spacing).目的是并且永远不会制作一个简单的HTML渲染器,因为它根本不可能,而是尝试尽可能准确.

对于示例页面,Google Chrome通常会以比FF快得多的速度加载它们.但是,对于某些页面(通常是较大的页面),Chrome会完全冻结,而Firefox会加载它们.现在,我一直试图找出确切的事情在哪里乱七八糟,但没有多少运气,因为它最终不会在Chrome中输出任何内容.

Chrome是否限制了在特定时间范围内可以执行多少画布绘制,或者页面可以使用多少系统资源？如果我根本无法从页面获得任何反馈(因为它只是挂起),我怎么能开始解开瓶颈？

示例(它应该做什么,是在页面顶部渲染画布图像,它应该看起来与实际HTML页面大致相同.您可以通过单击来切换画布图像(显示/隐藏).请不要如果您在浏览器中有未保存的工作,请打开它们,因为它可能最终也会挂起它们.):

简单测试,在FF/Chrome中工作正常

另一个简单的测试,在FF/Chrome中运行良好

完整页面,在FF/Chrome中运行良好

完整页面,仅适用于FF <4,Chrome冻结

他们都使用相同的js,可以在这里找到.

我不是在寻找一个超快速的脚本,就像渲染图像的仿真类型一样,我认为它甚至都不能完成.只是试图找到方法使它可能稍微更高效,而不会失去任何当前的功能.

Answer 1

问题似乎出在 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 提出的那样，但为什么它只在较新版本的 FF 和 chrome 上卡住，这是我需要更详细地查看的内容（大多数可能还没有可用的 image.width 或类似的东西）。