[whatwg] canvas elements <rect> <polygon> etc

[Philip Taylor]

On 12/03/07, ddailey <ddailey at zoominternet.net> wrote:
> I would like to believe that Canvas is useful, but being both naive and
> stubborn, I don't yet see why.
>
> In reading through the WHATWG draft, there are about N things that it seems
> to be talking about. I see N-2 of those as redundant with the SVG specs. The
> two components that jump out at me as missing from SVG are getImageData and
> putImageData -- the former being used, as I understand it, by Opera and
> perhaps others, to interrogate pixel values and to gather rectangular
> sub-bitmaps. Both of these are things that it would be nice (for me) if SVG
> had. The other N-2 things are already present in SVG,  in addition to N*5
> other things that are not in Canvas.

I think performance may be a worthwhile consideration: you can
probably emulate nearly all of the canvas capabilities in SVG, but it
wouldn't be fast enough for a number of interesting (though not
unarguably useful) applications. Benjamin Joffe's Canvascape [1]
(particularly the textured version), my Canvex [2], Matt Westcott's
Canvastastic [3], etc, are pushing slightly beyond the limits of
acceptable performance - but they do actually work, and I've seen
nothing comparable in the SVG world (although perhaps that's just
because I haven't been looking?)

As far as I'm aware, SVG isn't well suited to this because of the
immediate vs retained mode concepts - you'd have to destroy and
rebuild the document structure every frame, unless you do something
crazy to minimise the number of document changes between frames (and
then you probably get unpredictable performance and unpleasant
positive feedback effects). There's a better match with the canvas on
polyhedra.org [4] compared to some SVG 3D [5], where only vertex
coordinates need to change each frame, but that's a relatively limited
situation.

> In the meantime asking browser developers to implement both SVG and Canvas
> (given what looks like a high percentage of overlap in function) just seems
> like a way to artificially pump up staffing levels on browser development
> projects.

Mozilla's canvas implementation is only about three thousand lines of
code, while there seems to be ten times as much in its (incomplete)
SVG implementation. Much of the canvas code is just glue around the
existing 2D graphics library, which is (I believe) shared by the SVG
renderer and (from Firefox 3) the rest of the browser's graphics
system - so it fits in fairly easily with the technology that browsers
have to have anyway.


[1] http://www.abrahamjoffe.com.au/ben/canvascape/
[2] http://canvex.lazyilluminati.com/
[3] http://matt.west.co.tt/category/javascript/canvastastic/
[4] http://polyhedra.org/poly/
[5] http://www.treebuilder.de/default.asp?file=206524.xml

-- 
Philip Taylor
excors at gmail.com