Re: SVG vs canvas performance

On Sat, 2011-07-16 at 23:29 +1200, Robert O'Callahan wrote:
> First of all, animating the fishes is a pain in SVG. You either use an
> SVG element with an animated image, or an SVG element whose image href
> you change constantly. The former approach is hard because you want to
> be able to control the animation frame at which each fish starts, and
> there's no existing API for that. The latter approach would be hard to
> make fast since conceptually you'd be doing a full image load per fish
> per frame. In theory we could make it pretty fast, but you'll
> undoubtedly have more overhead than you do in canvas where you just
> pick the frame you want (by choosing the right source rectangle of the
> tiled image) and draw it.

I was thinking about a JS program controlling the repainting of Bézier
curves based on its opaque-to-browser script internals vs. the browser
repainting Bézier curves from a DOM-based scene graph onto a
smartly-preserved in-GPU compositing surface.

Maybe that case is the wrong case to consider and the cases where
developers choose <canvas> over SVG on performance grounds involve
sprite blitting instead. It didn't occur to me that sprite animation in
SVG isn't actually properly "retained". Now that I think about it, it's
rather tragic that SVG as the "retained" solution of the Web platform
isn't, on the level of what concepts it provides, facilitating
"retained" sprite animation where the sprite animation frames are
preloaded into the rendering pipeline and kept there.

> Handling transform changes could be an issue. If we unify CSS
> transforms with SVG transforms then transform changes would require
> some level of style reresolution, which would be significant
> overhead. 

I totally failed to consider the cost of the style system involvement.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 17 July 2011 13:13:14 UTC