# Animating DOM elements vs refreshing a single Canvas

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?

• 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. – Gustavo Maciel Jan 19 '12 at 2:59
• But... Why would you do that? I'm pretty sure a single canvas object would be much more efficient... – jcora Aug 6 '12 at 22:55
• @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. – mgibsonbr Aug 7 '12 at 0:17
• 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. – jcora Aug 7 '12 at 0:25
• @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). – mgibsonbr Aug 7 '12 at 0:34