His complaints about the API are ugly, (the point about paths being painful to draw, not enough primitives) are valid, but easily enough mitigated with a history lesson.
postscript was invented by the warnock and geschke of adobe, and was (according to wikipedia) adapted for use as a printer control language at the urging of steve jobs in 1985, shortly before steve jobs was booted out of apple. 1986 the laserwriter printer comes out with postscript, and steve jobs starts NeXT computers.
NeXT uses a system called display postscript, version of postscript adapted for interactive displays. NeXT gets bought by apple.
Apple adapts the NeXT OS into OS X. Due to some licensing issue, OS X no longer uses display postscript, but instead uses a different system with a nearly identical set of api calls called Quartz. (later, a bunch of other stuff got called quartz, so the system in question is now referred to as Quartz 2D)
The lineage is clear- Canvas is descended directly from Postscript, and if you look at the postscript language and compare, all the API calls are the same, along with this strange concept of a graphics “context”, basically an invisible object that holds a bunch of global variables, along with a save and restore commands which push and pop the graphics context to a stack.
if you’re just using the raw api calls, postscript doesn’t have those primatives either, and it’s just as onerous to draw a path. But most postscripts do NOT just sequentially call moveto/pathto etc in order to draw a complex path. The first thing at the top of a typical postscript file is a bunch of function definitions!
so instead of :
0 0 moveTo
20 0 curveTo
40 10 curveTo
0 0 curveTo
0 0 20 0 40 10 0 0 c
So it doesn’t have those primatives, but that’s okay because it’s not that difficult to add them, given the primatives we have. Curves are enough. If you have a graphics system that can only draw trapezoids, you can implement postscript on top of it, and any kind of shape you can think of on top of that. And you can create seperate graphics contexts to convert drawing instructions to different formats (such as PDF, or some printer language) without reimplementing the language interpreter.
Go forth and make contexts!
I think that API is as important as functionality it gives you access to. May be I am wrong.
I think it would make sense to create canvas2 and make it what it should of been, if it went through the review process we would get a much better result.
APIs that start life as propriety implementations are always destined to be ugly they never go through the review process and it’s usually built for a specific need and not thought about on a higher level. Drag and drop API is another example.
Let’s not confuse canvas and SVG. SVG is for when you need a scene graph, canvas is for fast-paced procedural drawing. Both API’s are not perfect, but they’re well enough suited to what they’re intended for, and they cover the scope of 2D drawing in the browser pretty much completely (especially once you can use canvas as an SVG element in a DOM structure).
What we need now is not endless redesigns to find the “perfect” API, but just browser implementors to step up and get the stuff that has been specced right in the first place. IE ofcourse needs to make a major upgrade here, but the other browsers don’t have perfect support of what has been specified either. They need to step it up.
That was an interesting slide share presentation on HTML5 and Canvas.
Yesterday I posted a video by Brad Neuberg from Google on my site. In this video “Brad talks about HTML5. He covers a lot of ground in this talk, including SVG/Canvas rendering, CSS transforms, app-cache, local databases, web workers, and much more.”
If anyone is interested they can check it out at this link http://ldfeeds.com/video/brad-neuberg-%E2%80%94-introduction-to-html5/ (shameless plug).
Meanwhile keep up the good work I am looking forward to hearing more from this site.