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

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:25 UTC