问题描述
|
我一直在进行一项实验,通过让javascript从加载的DOM中读取所有必要的信息,将HTML渲染为画布图像。由于canvas缺少CSS的许多标准部分,尤其是在涉及文本格式设置时,需要进行很多变通和性能密集的过程(其中“ 0”代表一个)。这样做的目的是并且永远不会做一个简单的HTML渲染器,因为这根本不可能,但是请尝试使其尽可能精确。
对于示例页面,Google Chrome浏览器通常比FF加载速度快得多。但是,对于某些页面(通常是较大的页面),Chrome会完全冻结,因为Firefox可以很好地加载它们。现在,我一直在尝试查明问题到底在哪里,但是运气不好,因为它最终不会在Chrome中输出任何内容。
Chrome是否对某个时间段内可以执行多少画布绘制或页面可以使用多少系统资源有一定的限制?如果我根本无法从页面获得任何反馈(因为它只是挂断了),如何开始解决瓶颈?
示例(应做的是在页面顶部呈现一个画布图像,该图像应与实际HTML页面大致相同。您可以通过单击来切换画布图像(显示/隐藏)。请不要\“如果您的浏览器中有未保存的工作,则不要打开它们,因为这也可能最终将它们挂起。):
简单的测试,在FF / Chrome中正常运行
另一个简单的测试,可以在FF / Chrome中正常运行
完整页面,在FF / Chrome中正常运行
完整页面,仅在FF <4下可用,Chrome冻结
它们都使用可以在此处找到的相同js。
我并不是在寻找一种快速的脚本,因为使用这种渲染图像的仿真类型,我什至认为它甚至无法完成。只需尝试寻找使它可能稍微更高效的方法,而又不损失其任何当前功能。
解决方法
从哪里开始?
分解。
使用相同的示例,并减少一半的工作量(您的呈现代码)。还是不行吗?再等一半,是否奏效?退回一半的钱。
与之类似,摆脱所有尝试的文本呈现或所有边框/填充代码。只是注释掉。那有用吗?
或者尝试仅注释掉199行上的
ctx.drawImage(img,x,y);
,然后别无其他。那有用吗?
如果您很幸运,您将能够确定Chrome花费大量时间做某事的关键点。
, 您是否尝试过使用Chrome \的内置性能分析器?
, 问题似乎出在css属性attribute2ѭ,特别是specifically3ѭ。注释掉
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或类似的内容)。