Re: SVG vs canvas performance

Summary of cases:

Highly presentational scenes: scenes with text extrusion and/or stylized 
ink input.
High bandwidth events: over 50 samples per second, such as pen [ink] 
input with pressure sensitivity .
High density scenes, animated and non-animated (IE Fish Demo, Maps with 
zoom)

In all of these cases, there is content that should be made available in 
the DOM,
and there are regional areas which correspond to that content and would 
be useful
to improve access.

I've replied in thread.

-Charles


On 7/16/2011 4:29 AM, Robert O'Callahan wrote:
> On Sat, Jul 16, 2011 at 3:11 AM, Henri Sivonen <hsivonen@iki.fi 
> <mailto:hsivonen@iki.fi>> wrote:
>
>     Do you have examples of people choosing <canvas> over SVG for perf
>
<snip>
>
>     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.
>
>
<snip>
> Overall I'd say there's a lot we can do to make simple image-blitting 
> workloads (which covers a lot of games for example) much faster in 
> SVG, but I'm very doubtful they'll ever be as fast in SVG as in 
> canvas, especially if the canvas code has been hand-optimized to use 
> explicit tiling. But we can probably make SVG "fast enough" so that 
> most of the things you would use canvas for are fast enough in SVG.
Explicit tiling is a lot of work; once it's written as a library,
it's easy to plug into, but it does take a lot to get started.

There is a lot of low hanging fruit for optimizing SVG animations,
"automatic" tiling included.

Most of the things that are slower with SVG relate to presentational 
effects.
Consider text extrusion: it requires many extra/presentational dom nodes.

There's not much of a way to manage repainting; if the user 
inadvertently shifts the viewport
on a touch device, the scene is re-rendered and it can be a bad experience.

The following shows simple text extrusion.
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/demo2.svg

I've used many more dom nodes, thousands, via svg+ecmascript to render 
scenes. On my mobile the scenes
are 10x slower with SVG than with Canvas.

High bandwidth input devices, such as pressure sensitive tablets
can be a little much, even for Canvas.

It'd help to see canvas offloaded from the main thread,
a way to manage serial devices via web workers and more DOM event types
for pressure sensitive pen and other devices.

> Your point about the canvas sub-DOM is relevant. If you require the 
> canvas implementation to be accessible (and I'm not sure what that 
> would mean for FishTank), you'll be adding overhead. How much overhead 
> is unclear.
http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html

The FPS meter might use more labeling, but it does at least update the 
canvas title.

Fish Tank does not have an interactive canvas gui, it uses html anchors.
Input type range could have been used.

One could represent areas on the screen, and annotate the density and 
variety
of fish that are swimming in the region.

This only requires a few DOM elements.


One of the major performance issues with SVG is that each element 
requires an entry in
the DOM with the exception of text.  This is actually a performance 
issue with HTML as well,
but it's generally been solved, or can be solved by simply swapping 
content in and out
of the dom in response to user scrolling or action. ARIA allows authors 
to handle corner cases
with the low level aria-live and aria-relevant attributes.

Canvas+ARIA aria-setsize and aria-posinset enable users to navigate an 
entire list of fish
while allowing only a subset of the scene to be available in the DOM at 
any one time.

Mapping applications may be a bit more appropriate an example than FishTank.
There are several mapping vendors, most of the rendering is done 
server-side,
but more-and-more can be done client side.

Maps, whether from Google, Microsoft or open source project
are an an impressive UI component.


-Charles