Regarding vector graphics performance, there's a weird way to use SVG that is sometimes much faster than Canvas: use string concatenation to build up a huge blob of SVG markup and then splat it into the browser all at once by setting innerHTML on an SVG element. We rely on this trick for UI performance in our web app. In fact, we do it on every scroll and/or mousemove. The amount of computation you can get away with in JS without noticeably slowing down the renderer is nothing short of astonishing.
Given how clunky SVG can be, it's surprising that this technique works so well. I believe the performance gain comes from batching everything you want to render into a single ginormous round trip between JS and native code. With Canvas, you don't have that option, so you have to cross the grand canyon with every call. The equivalent in SVG would be making a series of tweaks to the SVG DOM, and that's even slower. Much better to rebuild the entire DOM yourself in text and overwrite the old one.
As a bonus, you can take the same approach in IE using VML. Though the markup is different, the SVG and VML models are close to isomorphic - not close enough to abstract over without an annoying impedance mismatch, but much closer than either is to Canvas. Thus this technique affords a good way to get graphics performance out of both the modern browsers (SVG) and the pre-9 IEs (VML) for as long as the latter are around.
That approach you describe to building an SVG tree is a common performance optimization when manipulating the DOM for HTML as well. I'd be curious to hear if you've tried a) using a DocumentFragment, b) detaching the node using removeNode, manipulating, then adding it back, and c) simply working with a node (createNode) and then adding it in after manipulations are done. The basic idea is that working with the live DOM is slow, while working with detached nodes is fast. Note that I haven't really tried this stuff out that much. Maybe I'll work up a little benchmark over the weekend or something.
I'm pretty sure Paul Irish's talk [1, 2] is where I read about this.
Yes, using innerHTML to bypass the HTML DOM is the poster child for this kind of thing.
We've tried all the alternative techniques you mention (with HTML DOMs, that is - I don't think any of them work with SVG) and had disappointing results.
Given how clunky SVG can be, it's surprising that this technique works so well. I believe the performance gain comes from batching everything you want to render into a single ginormous round trip between JS and native code. With Canvas, you don't have that option, so you have to cross the grand canyon with every call. The equivalent in SVG would be making a series of tweaks to the SVG DOM, and that's even slower. Much better to rebuild the entire DOM yourself in text and overwrite the old one.
As a bonus, you can take the same approach in IE using VML. Though the markup is different, the SVG and VML models are close to isomorphic - not close enough to abstract over without an annoying impedance mismatch, but much closer than either is to Canvas. Thus this technique affords a good way to get graphics performance out of both the modern browsers (SVG) and the pre-9 IEs (VML) for as long as the latter are around.