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

On 7/29/11 8:18 PM, Alex Danilo wrote:
> A leak is a leak. What you're describing here is memory consumption
> which is completely different.

 From a user's point of view, there is no difference between "memory 
consumption that never goes away" and "a leak".  The technical 
distinction between them is not useful in practice either.  If your 
program is forced, during execution, to consume more and more memory 
which it all releases at shutdown that's not a "leak" in the technical 
sense, but it's a leak as far as anyone reasonable is concerned.

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

OK, I'm glad we agree on that.

> 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 other parts of the proposal seem fine to me, in general, so I'm 
commenting on the one thing that I see as an issue.

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

That's not acceptable, given how canvas is used on the web.

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

_If_ the web page author remembers to set width=width.  That is NOT 
something we can rely on, sorry.

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

I would assume the default would be discard anyway, to match HTML canvas 
behavior; principle of least surprise and all.

But even the non-default behavior should ideally work reasonably out of 
the box in ways that don't fail catastrophically if the web page forgets 
to put in a bizarre-looking width=width call....

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

Running out of memory is not acceptable for my users, sorry.

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

A typical "large" web page (cnn.com, say) has about 3000-5000 nodes on it.

A huge web page (the webapps single-page spec) has about 200,000 nodes 
on it.

The size of most DOM nodes in the implementations I've looked at 
recently is order of 100 bytes.  So we're talking maybe 500KB for a 
typical complex web site and 20MB for extremely large pages.

The uses I've seen on canvas recently were generating at least 10000 
drawing operations per second in modern browsers.

Looking at canvas, the smallest possible amount of state per operation 
(if you ignore fill() and stroke() calls once a path is built) is about 
8 bytes (for rotate() calls).  Most calls need a lot more memory than 
that, but let's be charitable.

That's 80KB/s of memory usage at 8 bytes per operation.  Or in other 
words, after 6 seconds you're using as much memory as the cnn.com DOM. 
After 5 minutes you're using more memory than the DOM for the entire 
webapps spec.

I understand the possible use cases for something like this, but it 
seems to be _very_ easy to misuse, as proposed.  Easier than it is to 
use correctly...

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

I think you're assuming people won't cargo-cult the property.  Trust me, 
they will.

I agree that used properly this would work quite well.  The question is 
how to make it hard to misuse.

-Boris

Received on Saturday, 30 July 2011 01:13:23 UTC