简体繁体 English

HTML Canvas 性能 - 导入图像或绘制 canvas

[英]HTML Canvas performance - import image or draw canvas

原文 2011-07-21 17:43:55 9 2 javascript/ html5/ canvas

For images of this complexity/simplicity, is it better to create pngs and import into canvas or draw the paths and fill on the canvas?对于这种复杂/简单的图像，是创建 png 并导入 canvas 还是绘制路径并填充 canvas 更好？

http://www.freeiconsdownload.com/site-images/Large/developer_icons_452x336.jpg http://www.freeiconsdownload.com/site-images/Large/developer_icons_452x336.jpg

2 个解决方案

With Canvas, in general, it is almost always better to draw from a PNG/in-memory canvas than to construct and draw a path.对于 Canvas，一般来说，从 PNG/内存中的 canvas 中绘制几乎总是比构造和绘制路径更好。 (see footnote) Here's some simple data. （见脚注）这里有一些简单的数据。 We're talking a factor of 10 here.我们这里说的是 10 倍。 For simple stuff.对于简单的东西。

Especially if you are going to draw those objects over and over, 60 times a second.特别是如果你要一遍又一遍地绘制这些对象，每秒 60 次。

And especially when text is involved .尤其是涉及文本时。

With complex canvas-generated shapes, several performance-minded people have taken to pre-rendering them on in-memory canvases and then drawing from canvas to canvas (using drawImage) instead of recreating the path each time.对于复杂的画布生成的形状，一些注重性能的人已经开始在内存画布上预渲染它们，然后从 canvas 绘制到 canvas（使用 drawImage），而不是每次都重新创建路径。 It is worth it in an awful lot of cases, but of course nothing can beat profiling and timing your own specific situation.在很多情况下这是值得的，但当然没有什么能比分析和计时你自己的具体情况更好。

Not to get off course, but I'd just like to remind that you probably shouldn't be worrying about this sort of thing until you are (nearly) finished with your Canvas app.不要偏离路线，但我只想提醒您，在您（几乎）完成 Canvas 应用程序之前，您可能不应该担心这类事情。

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" -Knuth “我们应该忘记小的效率，比如大约 97% 的时间：过早的优化是万恶之源”——Knuth

A big thing to note is that for a lot of applications, the performance of drawing these buttons might not even matter (or else have no tangible difference) and you probably do not want to even worry about which way is faster until you are already finished the first iteration of your Canvas app and are working on the "polish, polish, polish" update.需要注意的一件大事是，对于许多应用程序来说，绘制这些按钮的性能甚至可能无关紧要（或者没有明显的区别），您可能甚至不想担心哪种方式更快，直到您已经完成您的 Canvas 应用程序的第一次迭代，并且正在进行“抛光、抛光、抛光”更新。

Some may wonder when rendering paths on the fly is better and it's probably obvious to most but in case it isn't I will give it a mention.有些人可能想知道什么时候动态渲染路径更好，这对大多数人来说可能是显而易见的，但如果不是，我会提一下。 There are certainly times path-rendering-on-the-fly is the case: Interactive paths such as in drawing programs and animations born out of paths, where the next frame is not another still image but an addition to a path.有时候，路径渲染是这样的：交互式路径，例如在路径中产生的绘图程序和动画，其中下一帧不是另一个静止图像，而是路径的补充。 These and more - anywhere that you want to update the path itself with each frame - are the places that you'll want to keep paths and not try to pre-render anything.这些以及更多——你想用每一帧更新路径本身的任何地方——是你想要保留路径而不是尝试预渲染任何东西的地方。

I imagine that each browser would perform differently, it would probably be best to write a quick benchmark and time how long it takes to draw say 1000 of each type.我想每个浏览器的性能都会不同，最好写一个快速的基准测试并计算绘制每种类型的 1000 个所需的时间。

That being said, in terms of ease of programming, if you have the PNGs already why not use them as is.话虽如此，就易于编程而言，如果您已经拥有 PNG，为什么不按原样使用它们。