Re: SVG vs canvas performance

On Sun, Jul 17, 2011 at 6:12 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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.

Shouldn't you be able to preload the sprites into <pattern>s and just
swap the fill?

~TJ

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