Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I put together a couple of simple tests that render an image to a canvas. One renders from an IMG, while the other renders from an offscreen CANVAS. You can see the code and results here: http://jsperf.com/canvas-rendering/2

In most browsers rendering from an image is much faster than rendering from a canvas, except in Chrome, where the situation is reversed. Can anyone explain the reason for the differences? After all, we are rendering the same pixel data to the same destination.

share|improve this question
I'm not really sure this is a question, or at least one we could answer. Aside from that though, looking at your test it looks that just the others are really slow at rendering canvas objects, rather than Chrome being out of the ordinary for rendering images slower. –  Matt Kemp Jul 12 '12 at 22:25
But why is there a difference at all when in both cases they are rendering the same data? And the fact that at least one major browser has the opposite performance characteristic means we need to implement two code paths in our renderers. –  alekop Jul 12 '12 at 23:23
Could you add to the test rendering without either buffercanvas and img tag? Would be interesting to see. –  justanotherhobbyist Jul 13 '12 at 0:01
@hustlerinc: You mean render from a canvas onto itself? What would that prove? All the game's graphics are loaded from images, so you have to use an image at some point in the process. –  alekop Jul 13 '12 at 21:42
@alekop No, I mean skipping the offscreen canvas and just using one canvas. I think in web it should make rendering faster, but don't have proof for it. And too lazy/inexperienced to do the test myself. –  justanotherhobbyist Jul 13 '12 at 21:45

4 Answers 4

OK, I figured it out. Almost. It's actually quite obvious, and I feel a bit dumb for not noticing this right away. When you call drawImage(src, 0, 0) without specifying width/height it draws the entire src region, which in this case is much larger (the canvas is 320x420 versus the img at 185x70). So in the canvas case the browser is doing much more work, which explains the slower performance. I' still puzzled by Chrome's higher score with the larger src.

dest.drawImage(src, x, y) // bad
dest.drawImage(src, x, y, w, h, destX, destY, w, h) // good

I've posted an updated version which uses the same regions, and the differences are much closer. http://jsperf.com/canvas-rendering/5

I still can't explain why there is a difference, but it's now small enough that I don't really care.

share|improve this answer
On Chrome 43 with Windows 8 and Intel Graphics HD it crashes when the first test runs. When the test finishes drawImage(img) is the clear winner, drawImage(canvas) being 94% slower. –  serbanghita 2 hours ago
Firefox 38 runs smoothly, no problems at all, and the both tests are close. –  serbanghita 1 hour ago

Chrome is likely to use hardware acceleration.

Create a canvas 240x240 and run your experiment in Chrome then create a canvas 300x300 and do it again. The larger canvas I expect to be faster due to the fact hardware acceleration kicks in after 256x256 and chrome uses software when the sizes are less.

Also it worth pointing out that -webkit-transform:translateZ(0) turns off hardware acceleration.

I haven't tested any of the above; I only know this due to the fact one of the chrome engineers commented on a bug I reported in chrome when you cross the hardware and software threshold by dynamically resizing the canvas from larger to smaller than the 256x256 boundary or vice-versa. The solution to this bug was to turn off acceleration using the translateZ as mentioned above.

In my case, I simply did not allow users to resize less than 256x256.

share|improve this answer

Can't explain the differences, but I'd disagree with

And the fact that at least one major browser has the opposite performance characteristic means we need to implement two code paths in our renderers. - alekop

If you look at the results on the js.pref the differences in chrome are fairly subtle. I'd stick with just rendering from an image when possible.

share|improve this answer
The trouble is that I'm relying on offscreen canvases to compose complex images. For example, I'm rendering a character's animation frames into an offscreen buffer, and then rendering things like clothing/armor/weapons on top. The game then renders from the composite canvas, rather that re-rendering all these details for each character, each frame. With canvas-to-canvas performance being so poor in non-Chrome browsers, I'd have to render the composite back into an image. It's not the end of the world, but I was hoping there is a workaround. –  alekop Jul 13 '12 at 21:31

Sometimes images might be loaded to GPU memory and canvas in host memory. In that case when you draw from image to canvas the image data has to be copied first to host memory and then to canvas.

I noticed that kind of behaviour with Chrome, when I was writing project which loads over 100M pixel images and then reads parts of them to small 256x256 canvas ( http://elhigu.github.io/canvas-image-tiles/).

In that project if I drew directly from image tag to canvas in Chrome, memory always jumped to ~1.5GB when drawing started and then when drawing ended memory was freed again, even that 250 megapixel source image was shown all the time in the page.

I fixed the problem by writing image once to big canvas (same size with image) and then drawing smaller canvas from there (I also threw image away after converting it to canvas).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.