- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 5 Nov 2004 13:57:03 +0000 (UTC)
- To: Antoine Quint <ml@graougraou.com>
- Cc: www-archive@w3.org
On Fri, 5 Nov 2004, Antoine Quint wrote: > > > > [Taken off www-svg since JonF requested that I not send non-SVG-related > > content to the www-svg list. cc'ing www-archive instead.] > > Let's just say that you might not make as much of a fool of yourself on this > list where no one is aware this thread continues. Well done. It should be quite clear by now that I have no worries about looking like a fool. If you want to forward my message (or this one) to www-svg, feel free to do so. Jon asked me not to, I'm acquiescing to his request. > > > Can you elaborate on how <canvas> makes dynamic graphics generation > > > easier with a concrete example? > > That's just code, not a detailed analysis about how <canvas> is a fitter > contribution to web development than SVG for the creation of "dynamic > stock graphs, maps, and the like". My apologies, I thought by "concrete example" you meant "code". What did you mean by "concrete example"? If you want "a detailed analysis about how <canvas> is a fitter contribution to web development than SVG for the creation of "dynamic stock graphs, maps, and the like"", then you are asking the wrong person, since I never said that it was. I did say that "dynamic stock graphs are easiest done with something like Apple's <canvas>". I think that is true, because updating path data in an SVG fragment is harder than simply plotting a new line using the canvas APIs. I may be mistaken. A better example of something that <canvas> makes easier is things like games (things like Doom, platform games, etc). When you need fast frame rates, where you really don't need a DOM, where objects will be created and dropped at a moment's notice, where bitmap sprites are to be thrown around like there's no tomorrow, etc. But I never said that <canvas> was better than SVG. I didn't even compare them. I don't think they are competing technologies. I'm recommending that Web browsers implement both <canvas> (and the rest of Web Apps, once it's ready) and SVG 1.1. > > Say you wanted to draw a circle around a point on a photograph, as > > part of a Web page. Radius 10px, two pixel black stroke, no fill. In > > the examples below I've omitted the fallback content in both versions, > > in order to concentrate on the differences. > > You sure didn't ignore the pedantic programming style to make sure your > comparison was well-biased. I used the SVG DOM, on the assumption that it was designed to be better than the Core DOM (otherwise, what's the point in having it). > First, strip off the <html> that you don't need in that case, and the > stylesheet since we don't need it anymore (you can't position a circle > using CSS in SVG). The context of this was a a photograph in an HTML document. So you need the <html> there, and you need the stylesheet to position the <svg> element itself. If you drop <html> and the stylesheet, you might as well drop it in the <canvas> case too, and use <canvas> as the root element. It makes about as much sense. > Code length doesn't have anything to do with code complexity by the way. > I trimmed down DOM calls to a minimum here, but if you wanted to do it > in a more verbose and possibly clearer way (using a separate > setAttributeNS() call for each attribute) then complexity remains the > same as it's only one method reused all over again. Your example still looks more confusing than the <canvas> equivalent, to me. But I guess it's a matter of personal preference. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 5 November 2004 13:57:06 UTC