Re: Minutes, July 15 2009 SVG WG telcon

On Wed, 15 Jul 2009 12:56:21 +0200, Robin Berjon <robin@berjon.com> wrote:

> On Jul 15, 2009, at 10:08 , Cameron McCormack wrote:
...
>    - I think it's worth experimenting a little bit with various APIs
> before committing to them.

Yes absolutely. From the discussions in the July 15th telcon it seemed like the canvas path API was desirable. However, that doesn't give you access to segments once they've been created. Also the SVG Tiny 1.2 SVGPath API is quite similar to what the canvas path methods offer, plus the ability to inspect created segments (drawbacks: it's readonly, doesn't do arc segments, rects or circles).

The SVG 1.1 PathSegList interfaces provide some additional benefits in that it gives read-write access to segments in the paths. The thing that I personally dislike about it is the notion of having a normalized and a non-normalized segmentlist that are always synchronized with each other. If there is a need for having both the normalized and non-normalized list at all (I guess there is, but it'd be even simpler if that wasn't the case), then if there was a method to get either of those two from a path element that would be much better. And I would prefer if when you do get both of those lists, that they're not automatically synchronized and only one of them is actually "live".

 From experience, much of the overhead (and complexity) of the PathSegList interfaces come from the keep-lists-in-sync-at-all-times requirement. I would like to see that requirement dropped.

The combination of the SVGPath interface and the SVGPathSegList interfaces could be a solution possibly, use the path creation methods from SVGPath, then inspect and change segments with the methods given in the SVGPathSeg* interfaces.

...
>    - Before blaming DOM manipulation for all of the trouble (though it
> certainly is the reason for a large part of it) it would be nice to
> have actual numbers so that we could measure the improvements. I'd
> further like to know if other parts of SVG (SMIL, use, non-native text
> layout) contribute to the overhead. Maybe some of our implementer
> friends could give us some profiling information (or at least some
> vague data)?

It's certainly true that a large share of the svg overhead compared to the canvas API is bookkeeping and DOM mutation management. You don't have to do that with canvas, it puts the entire burden on the content author. That plus having a full DOM (read: large document) contribute to memory overhead as well.

Imagine the case where you change an attribute, and suddenly you need to redraw the entire SVG (traversing, rendering etc). In canvas you instead clear the area you need to clear, then re-render what you need, in some cases you might not even need to clear something. And there's no tree traversal overhead, or mutation management overhead.

SMIL, I've seen cases where it's slow, but it's also largely related to bookkeeping, or to having very large DOM trees (something SMIL contributes to by not being very reusable).

Use element: in Opera, more efficient than having the equivalent DOM tree folded out (deepcloned), both memory and processingwise. Making a better use element might be interesting though, I don't really like the way inheritance works because it makes it harder to reuse use :) It's possible that some of that can be fixed with the SVG Params spec though.

Non-native text layout: usually a bit slower than simple aligned "trivial" text sure (thinking stroked text, rotated text, text-on-path etc). It shouldn't be much slower for the simple cases though, but there are many cases where SVG text handling is non-trivial.

The 'buffered-rendering' property from SVG Tiny 1.2 can address some of the overhead of repainting expensive subtrees, at the expense of memory (similar to a background raster image).

>    - There exist some "simpler DOM" efforts, such as the Web DOM[1],
> we might want to look there as well.

getAttribute/setAttribute? Well, IMHO SVG needs something a bit more than Web DOM to be really useful. There's overhead in stringifying floats and parsing floats all the time too.

> The canvas API is very low level, which has spawned a number of APIs
> on top that make simple things simple (like, say, drawing a circle). I
> think we should list and investigate those (e.g. Processing.js, which
> I've been meaning to show working on top of SVG — it shouldn't be much
> pain). And while we're in there, there are quite a few handy animation
> APIs we might want to take a look at.
>
> [0] http://berjon.com/hacks/canvas-getsvg/
>      http://code.google.com/p/canvas-svg/
> [1] http://simon.html5.org/specs/web-dom-core

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 15 July 2009 15:16:02 UTC