W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: SVG vs canvas performance

From: Chris Marrin <cmarrin@apple.com>
Date: Mon, 18 Jul 2011 10:35:08 -0700
Cc: Henri Sivonen <hsivonen@iki.fi>, Jonas Sicking <jonas@sicking.cc>, Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html@w3.org>, Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>, David Singer <singer@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Edward O'Connor <hober0@gmail.com>, Canvas <public-canvas-api@w3.org>
Message-id: <1A8194AD-C6C0-494F-8D3F-FA4B351AE797@apple.com>
To: robert@ocallahan.org

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
Received on Monday, 18 July 2011 17:35:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:36 GMT