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

Hi David,

--Original Message--:
>On Saturday 2011-07-30 09:38 +1000, Alex Danilo wrote:
>> I very much doubt any capable implementer would find managing
>> the replay memory to be difficult or a source of leakage.
>
>The term "memory leak" doesn't only refer to memory that the
>implementation forgot to call free() on; it refers to memory that is
>being used unnecessarily.  In that sense, which is the sense in
>which Boris is using it, the term can be applied to languages in
>which memory allocation and deallocation is managed by the language
>runtime.

Not really.

A leak is a leak. What you're describing here is memory consumption
which is completely different.
Lots of allocation/deallocation can also cause memory fragmentation which
is an issue in embedded systems,

However this is all off the track. The original proposal just described blindly
building a 'replay' buffer which would be unbounded and so, yes not
a direct match for what canvas in HTML does (in its working draft form).

But that is part of the point of the proposal - i.e.  a mechanism that
provides added functionality over HTML canvas, and no one has
even bothered to comment on the general proposal, instead locking
into _one_ aspect and painting it red.

>The key problem here is that canvases may have millions of drawing
>operations, some of which overlap others.  Maintaining a data
>structure that maintains all drawing operations whose effects are
>still visible while discarding those that are not, at a small
>constant time (not amortized) per drawing operation, is not a
>trivial task, but I'd argue it's the minimum acceptable standard
>given the way canvas is used.

Agreed.

The replay buffer is intended to be verbatim - no optimization of
the content expected, hence no runtime overhead apart from
memory consumption.

If the canvas is being redrawn say for each frame of a video, then
setting the width=width (as described in my original mail) would
blow away the entire replay buffer, so handling millions of frames
of continuous video would free the memory up anyway.

And as I said in my last mail, if the default was changed to discard
this is no longer an issue.

Since we provide replay capability by adding the retain mode, it needn't
be optimizing - just a single vector of paint commands that will grow
unbounded until the canvas is destroyed or you run out of memory.

_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.

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.

Alex

>-David
>
>-- 
>𝄞   L. David Baron                         http://dbaron.org/   𝄂
>𝄢   Mozilla Corporation               http://www.mozilla.com/   
>

Received on Saturday, 30 July 2011 00:18:39 UTC