After quite a lot of experimentation with HTML5 canvas, I’ve figured out a way to use it with the kind of big isometric game worlds used for Germination X which are built from hundreds of overlapping sprites. There are lots of good resources out there on low level optimisations, but I needed to rethink my general approach in order to get some of these working.
It was quite obvious from the start that the simple clear screen & redraw everything way was going to be far too slow. Luckily HTML5 canvas gives us quite a lot of options for building less naive strategies.
The secret is only drawing the changes for each frame (called partial re-rendering in the link above). To do this we can calculate sprites which have changed and the ones they overlap with. The complication is maintaining the draw order and using clipping to keep the depth correct without needing to redraw everything else too.
In the game update we need to tag all the sprites which change position, rotation, scale, bitmap image, transparency etc.
Then in the render loop we build a list of all sprites that need redrawing, along with a list of bounding boxes for each overlapping sprite of the changed sprites that touch them. There may be more than one bounding box as a single sprite may need to be redrawn for multiple other changed sprites.
For each changed sprite:
Get the bounding box for the changed sprite
For each sprite which overlaps with this bounding box:
If overlapping sprite has already been stored:
Add the bounding box to overlapping sprite's list
Else:
Store overlapping sprite and current bounding box.
Add the changed sprite to the list.
Assuming the sprites have been sorted into depth order, we now draw them using the list we have made (we would only need to loop over the redraw list if we built it in depth sorted order).
For each sprite:
If it's in the redraw list:
If it's not one of the originally changed sprites:
Set a clipping rect for each bounding box.
Draw the sprite.
Turn off the clipping, if it was used.
With complex scenes and multiple moving objects, this algorithm means we only need to redraw a small percentage of the total sprites visible – and we start to approach Flash in terms of performance for games (I suspect that flash is doing something similar to this under the hood). The code is here, currently written in HaXE, but will probably end up being ported to Javascript.