- From: Alex Danilo <alex@abbra.com>
- Date: Fri, 29 Jul 2011 23:04:23 +1000
- To: www-svg@w3.org, public-svg-wg@w3.org
Hi All, Firstly, thanks for the great minuting - it's very readable and clear and substantive! Anyway, I've spent most of today trying to build a demo of canvas in SVG to send tonight but it isn't quite done yet. In any case, I have a few comments about what people seem to have said and what I was trying to build as a demo to discuss: 1) putting <canvas> in SVG is a great idea, and the 2 technologies are very symbiotic and serve different purposes; and 2) I agree with Brian's sentiments about what that buys us if we put it in natively vs. just using foreignObject and embedding HTML<canvas>. So, since we are the scalable side of the world:-) my take is that we should provide the scalable canvas. This is what I was attempting to build today as a potential proposal. Dean made comments about scaling, pixellation etc., Vincent commented about the size/zoom events etc. triggering JS to redraw, and there were some other comments regarding retained state, etc. that elude me now. So, as one idea (and what I was attempting to prototype to send today but didn't finish) is: * <canvas> in SVG exposes the same API as <canvas> in HTML. No changes unless necessary for the different models (more below). * <canvas> in SVG works in user units, <canvas> in HTML remains in px. * <canvas> in SVG defaults to retained mode, i.e. we can have an attribute or property retain="retain|discard" that controls what happens to the drawing commands on the canvas when resize/zoom occurs. * As default retain="retain", the UA buffers all drawing to the canvas and when resize happens, regenerates the backing store and replays the render commands at the current resolution. * If retain="discard" we get the same behaviour as HTML <canvas> and bitmap rescaling must be done. So, justifying why this is a useful approach: 1) Just sticking <canvas> as is into SVG buys us nothing. 2) Making the backing store adaptable with re-render on size/zoom makes the SVG <canvas> a scalable solution that doesn't show any pixellation. 3) Defining this as a replay of render commands type of surface generates no runtime penalty unless the surface changes size, so in effect it should be as fast as normal HTML <canvas> under static conditions. 4) If the surface is resized, the replay of render commands buffer should be very lightweight compared to DOM nodes for each render operation. 5) Serialization of the render commands into DOM representation should be moderately trivial. 6) Clearing the canvas as per usual JS things like setting the width = width can clear the render command buffer and manage memory consumption well. 7) Same JS APIs, same authoring learning curve for simple co-ordinate systems and same functionality. If this type of <canvas> was brought into SVG then we expose a superset. If the SVG viewport/viewbox is just px then the canvas behaves the same. If we add scalability via percentages, etc. then the painted commands just work when the window is stretched, etc. with no pixellation artifacts. Anyway, I'd hoped to build this today to show you what I mean by this idea but didn't get it done. I hope you guys understand the intent and provide some feedback. Alex
Received on Friday, 29 July 2011 13:08:17 UTC