A few years ago, when the HTML Canvas element was still kinda fresh, I wrote a small game in a rather "unusual" way: each game element had its own canvas, and frequently animated elements even had multiple canvases, one for each animation sprite. This way, the translation would be done by manipulating the DOM position of the canvases, while the sprite animation would consist of altering the visibility of the already drawn canvases. (z-indexes, of course, were the tricky part)

It worked like a charm: even in IE6 with excanvas it showed a decent performance, and everything was rather consistent between browsers, including some smartphones. Now I'm thinking in writing a larger game engine in the same fashion, so I'm wondering whether it would be a good idea to do so in the current context (with all the advances in browsers and so on).

I know I'm trading memory for time, so this needs to be customizable (even at runtime) for each machine the game will be running. But I believe using separate canvases would also help to avoid the game "freezing" on CPU spikes, since the translation would still happen even if the redraws lag for a while. Besides, the browsers' rendering engines are already optimized in may ways, so I'm guessing this scheme would also reduce the load on the CPU (in contrast to doing everything in JavaScript - specially the less optimized ones).

It looks good in my head, but I'd like to hear the opinion of more experienced people before proceeding further. Is there any known drawback of doing this? I'm particulartly unexperienced in dealing with the GPU, so I wonder whether this "trick" would nullify any benefit of using a single, big canvas. Or maybe on modern devices it's overkill (though I'm skeptic about the claims that canvas+js - especially WebGL - will ever be a good alternative to native code). Any thoughts?

  • \$\begingroup\$ Not sure, but i still think just one Canvas is better. If blocking loop with redraws is a problem for your game, consider fixing you timestep. \$\endgroup\$ Jan 19, 2012 at 2:59
  • \$\begingroup\$ But... Why would you do that? I'm pretty sure a single canvas object would be much more efficient... \$\endgroup\$
    – jcora
    Aug 6, 2012 at 22:55
  • \$\begingroup\$ @Bane Do you have any reason to believe that? My tests showed the opposite, especially for older browsers... My common sense also says that DOM operations - implemented in native code - should be faster than Canvas drawing - done in JavaScript. \$\endgroup\$
    – mgibsonbr
    Aug 7, 2012 at 0:17
  • \$\begingroup\$ Because you would still need to actually draw things? And because each canvas element would consume memory? I don't see how this would be any faster, only slower/more memory intensive. \$\endgroup\$
    – jcora
    Aug 7, 2012 at 0:25
  • 1
    \$\begingroup\$ @Bane yes, as I said in the question, I was trading memory for time. By using several pre-rendered canvases, you don't need to re-draw them at real time, so it gets really faster. But the more complex your scene is, more and more the memory cost becomes prohibitive (which should be a problem for mobile devices, for instance). \$\endgroup\$
    – mgibsonbr
    Aug 7, 2012 at 0:34

1 Answer 1


One canvas should allow for much more generalized, easy to read code. Even if multiple canvases do make for better performance, one should easily have enough performance for any user to be satisfied. Also, should you drop your code on someone to maintain, or someone would like to learn off of it, it will probably be easier to use the widely accepted method.

  • \$\begingroup\$ It's been a year since I asked the question, and HTML5 Canvas support (and performance) has greatly improved - including new frameworks targeting it, such as KineticJS. In these circumstances, I guess your answer is indeed the most sensible one... \$\endgroup\$
    – mgibsonbr
    Jan 9, 2013 at 10:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .