W3C home > Mailing lists > Public > public-html@w3.org > June 2009

Re: Canvas - SVG Bridge

From: Robin Berjon <robin@berjon.com>
Date: Mon, 29 Jun 2009 15:06:50 +0200
Cc: www-svg WG <www-svg@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
Message-Id: <33858D25-EE58-47D9-BACD-A5C472DCE7AD@berjon.com>
To: Klaus Förster <klaus.foerster@uibk.ac.at>
Hi Klaus,

On Jun 29, 2009, at 14:39 , Klaus Förster wrote:
> well done Robin,


> maybe we should tell browser vendors to implement what the HTML 5  
> spec already mentions under canvas.toDataURL([type,...]): "The  
> possible values are MIME types with no parameters, for example image/ 
> png, image/jpeg, or even maybe image/svg+xml if the implementation  
> actually keeps enough information to reliably render an SVG image  
> from the canvas" [1]

Yes, I was thinking around those lines, but it's not entirely simple.  
Right now, I don't think that any implementation keeps any information  
around, because there's no real need to. And keeping information  
around has a non-negligible cost. The structure I keep around to make  
this happen is rather lightweight, and could easily be made lighter  
still, but if you have a canvas element being updated regularly over a  
long time it'll nevertheless add up to a huge lot of information over  
time. It's certainly not what you'd want by default.

Part of this experiment was done precisely to evaluate this option  
though, so it's not as if I'm against it. One option would be to have  
an attribute either on the context or on the element along the lines  
of keep-memory=true. When enabled it would keep track of canvas  
operations so that they could be retrieved later, and when not it  
would be impossible to extract SVG from the canvas.

The main question is: are there sufficiently strong use cases that  
motivate this? I'm not convinced that the answer is yes. What's more,  
having demonstrated that it can be done in script with very little  
performance cost, do we really need to add this to the browsers? I'll  
let vendors comment on this, and of course I'm sure they'd value use  
cases that people here might have that would justify supporting this  
natively (or not).

> Your library could act as "reference implementation" to get a better  
> idea what "keeps enough information" and "reliably render an SVG  
> Image" could mean, could it?

I don't think that it would be a reference implementation, we tend not  
to do that for web specs. But it can certainly be a proof of concept.  
What's more, its live mode can also be used as a testing ground for  
new canvas features without requiring people to hack directly on  
browsers. This can be seen with the transform options that aren't in  
browsers but work in my script.

Since there's been a fair bit of interest around this and a few change  
requests, I'll be putting it on Google Code later today.

Thanks for your feedback!

Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Monday, 29 June 2009 13:07:32 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:49 UTC