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