- 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