Re: Canvas in SVG, was: Re: minutes, SVG WG Seattle F2F 2011 day 1

On 7/29/2011 5:18 PM, Alex Danilo wrote:
> _But_  the nice thing about the playback array is that it should consume
> a minimal amount of memory compared with the kilobytes consumed
> by some DOM implementations per node.
Canvas is not repainting through DOM implementation, it's running via JS 
objects
and method calls.
> This is not unlike the PDF vs. Postscript model. Postscript was a language
> to draw things, PDF is the output serialization of the interpreter.
>
> Horses for courses, if you have a need for retaining the canvas operations
> then set the property. I'll bet you the redraw will be quicker than handling
> the event and running a whole bunch of Javascript_again_  for the
> cases where this behaviour would be desirable to an author.
This is basically how WebGL operates.

But it doesn't work with curves. The curve operations outweigh most method
overheads -- you're not going to see a substantial gain in performance, 
though
you will see some, through the memory/instructions trade-off. The JS 
code may
be faster in some cases; the author could even add conditionals, to make 
it faster.

I've recommending that something like fillPath or .path(DOMString) be added
to the Canvas2d spec, as an option for authors to use to minimize JS 
method calls (and some JS code)
for paths.

I've asked around about a managed canvas; some implementations do indeed 
buffer canvas
drawing commands, though those buffers can be flushed at any time. It's 
a lot
of work on implementers; when left to authors, it's something that 
authors can optimize to suit
their needs.

Doug Schepers is investigating a new graphics API, and I believe that
the retain-switch you're hoping for would work well in that API.

I work with WebGL, SVG and Canvas, shifting data between them,
it'd be nice to have an API to follow.

-Charles

Received on Saturday, 30 July 2011 00:59:10 UTC