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.
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.
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.
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).
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.
The image's size is 185*70 but we create a canvas with size, I think this will waste some performance, so I set the offscreen canvas's size same as the image. And the difference is closer.
var g_offscreenCanvas = createCanvas(185, 70);
