- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 29 Jun 2009 15:06:50 +0200
- To: Klaus Förster <klaus.foerster@uibk.ac.at>
- Cc: www-svg WG <www-svg@w3.org>, "public-html@w3.org WG" <public-html@w3.org>
Hi Klaus,
On Jun 29, 2009, at 14:39 , Klaus Förster wrote:
> well done Robin,
Thanks!
> 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