I'd also point out that with SVG a more reasonable comparison would be to
load in an image which contains multiple cells as an image, then just change
the viewport on that image, rather than loading in individual cells - in
essence the same kind of operation as you would do in Canvas. In most cases
changing the viewport just involves changing the x and y attributes via
Javascript. This becomes more advantageous if you have multiple sprites that
use the same image - you'd need to load the same image only once for all the
sprites.
Again, I'd have to see what the metrics look like for something like that,
but I suspect that memory usage would be lower for the SVG implementation,
perhaps at the cost of slightly less efficient animations.
Kurt Cagle
Information Architect
Avalon Consulting
On Mon, Jul 18, 2011 at 1:35 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Jul 16, 2011, at 4:29 AM, Robert O'Callahan wrote:
>
> > On Sat, Jul 16, 2011 at 3:11 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> > Do you have examples of people choosing <canvas> over SVG for perf
> > reasons? Are the perf reasons data-based or merely assumed? Are the perf
> > reasons the kind of quality of implementation issues that can be
> > considered to be transient and addressed over the next couple of years?
> >
> > In theory, SVG should be able to outperform <canvas> for painting,
> > because the browser engine gets to control how often to repaint, what
> > parts to repaint and can avoid intermediate bitmaps when the path
> > stroking and filling can be performed nearer hardware and there are
> > guaranteed not to be readbacks because the browser knows there aren't
> > filters in use.
> >
> > So in theory, if SVG has performance issues, they should be attributable
> > to the DOM. If a sub-DOM is used for accessibility in the <canvas> case,
> > then the <canvas> case has a DOM, too.
> >
> > heycam and I talked this through over lunch the other day as a thought
> experiment. Basically, we compared what the browser does with the IE
> FishTank demo vs what the browser would do with a hypothetical,
> naturally-written SVG FishTank demo. (Assuming 2000 fish since everyone
> maxes out at 60fps on 1000 fish on high-end systems these days.)
>
> I think this is the wrong comparison to use for this particular test case,
> for a couple of reasons. First, most browser vendors have done a lot of work
> recently on improving Canvas performance. The same can't be said about SVG.
> So Canvas is going to be significantly faster than SVG for that reason
> alone. The reasons for this work, IMHO, is simple. Canvas is a simple API.
> Improve the rendering performance and you see all those gains on the screen.
> SVG requires not only rendering improvements, but also improvements in
> managing the DOM and tree traversal. All of these can (and I believe will)
> be done eventually. But so far Canvas is way ahead in using modern
> acceleration techniques.
>
> Second, SVG is probably not even the best tool to use for this demo. It is
> basically just a bunch of images blitting around the screen. The better
> comparison would be to make a version using HTML images and CSS for
> animation. I haven't done the test myself, but WebKit would at least be able
> to give Canvas a run for its money since it accelerates both the rendering
> and animation of demos like this. We recently added the "step" timing
> functions which make flipbook animations much simpler.
>
> I'm writing this test now. Maybe I'll have some results in a day or two.
>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>
>