Thursday, October 15th, 2009

HTML5 Canvas FTW!

Category: Canvas, Presentation

Dmitry Baranovskiy, of Raphaël fame (can’t forget the umlauts), has posted an excellent presentation on the Canvas tag from Web Directions South ’09:

Posted by Brad Neuberg at 6:30 am

2.7 rating from 55 votes


Comments feed TrackBack URI

Choaked… my ……. browser……….. must……………… reboot …………………………..

Comment by sourceRoot — October 15, 2009

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)
Version 10.4 of OS X rolls around, and Apple needs their new HTML/javascript based dashboard system to really pop, so they wrecklessly add something called the “canvas” tag, which is a light wrapper around quartz 2D, with only one context (As opposed to on on screen context, and also a PDF context as is available to Quartz2D);
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
you’d have
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.
It’s a beautiful design, and javascript has been graced with a very quickly slapped together wrapper into that power.
Go forth and make contexts!

Comment by Breton — October 15, 2009

What is good for PostScript not as good for JavaScript. I can write wrappers around the API, but this is not what I want. We already have one quite inconvenient API—DOM. I would like Canvas to be more convenient, that’s it.
I think that API is as important as functionality it gives you access to. May be I am wrong.

Comment by DmitryBaranovskiy — October 15, 2009

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.

Comment by Ahrjay — October 15, 2009

What canvas needs is a native scene graph library so that we don’t need to implement this in JavaScript. Currently, handling events in the canvas element is painful. You need to figure out what WITHIN the canvas element the user is clicking on. We need a jQuery like API for handling events in canvas.

It would also be nice, as is mentioned by Dmitry in his presentation, if the canvas api was a bit simpler. By this I mean for drawing vector shapes – something SVG is excellent at. Applying styles should be easier, drawing shapes like circles, paths, triangles, etc should be easier. Currently, all of that needs to be written using JavaScript.

Comment by devongovett — October 15, 2009

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.

Comment by Joeri — October 16, 2009

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 (shameless plug).
Meanwhile keep up the good work I am looking forward to hearing more from this site.

Comment by LiveDevFeeds — October 16, 2009

Leave a comment

You must be logged in to post a comment.