HTML5 Canvas Performance - should we be worried?

Here is a Tweet from Grant Skinner that surprised me, since Grant is one of the pioneers in Canvas development, having his team develop EaselJS, a framework that puts sense into the mess we call Canvas.
Grant claims that HTML5 Canvas performance is something to be worried about, as it appears to be sluggish, and I must say that from the experiments I've done with it, I've noticed that too...
Knowing Grant's work, I'm pretty sure that he had tested and benchmarked all there is (and probably still is) to back his assessment.

I, like Grant, would really like to know what Steve Jobs has to say about it.

HTML5 Context Updates :: Are you serious?

Hi guys,

So HTML5 is out there and the Canvas is one of it's big promises (aside from the fact that all that is being done so far as for samples of what can be done with it, was available, like, 10 years ago with Flash 4, but let's not let the facts confuse us).

As a technologist in spirit and a Lego-boy at heart, I jumped at the opportunity to play with the Canvas and get my hands dirty with it's bits and bytes. I guessed it would be a good idea to share my experience with it, especially from a Flasher point of view, since you have a lot of HTML-ists out there that are so excited that things move on their screen just by writing HTML and JS that are ready to claim that Flash is dead.

I'm not going into the tools and libraries that are popping up everywhere, but rather to what the technology offers in the means of rendering and controlling the graphic objects on the stage (can we call it that? Yeah, sure, why the hell not).
So it appears that each Canvas has it's own context. This context is where you draw your stuff on and is the object you render.

Let's say you want a ball to move from the left to the right. Simple enough in Flash, you create a ball, throw some motion Tween on it, and you're good to go. Not so much in HTML5 Canvas.
In HTML5 you draw the ball on the left, and each time you want the ball to move, you update it's coordinates and draw it once more. This goes on until the ball has reached it's goal position.

Now, some may say that this is what happens under the hood in the Flash Player, but the bottom line is that you have to make this "update coordinates-clean context-redraw" every time you wish something to move on your screen.

This means that if you have objects for each player in your new game, you have to implement the "update" and "redraw" methods, and moreover - call them manually (on a timer or what have you).
Does this suck? Hmmm… A bit. It's like you have a heart beat (or EnterFrame) which is not a core part of the technology, but rather a pace maker the developer needs to control.

This makes me realize that although you can draw and move stuff on HTML5, the framework is so immature in compare with Flash/Flex, that it makes the comparison a bit embarrassing.
This certainly does not mean that it's not heading the right way in full speed (given that the path has been laid before, now we only need to convert it to HTML5), but it would take some time.

I will be here, monitoring it and getting my hands dirty…
Until then… Have a good one :)