Another way: use the canvas2d implemented on WebGL[1], which is hardware accelerated. The biggest drawback is that canvas2d is far more supported than canvas3d.

[1] https://github.com/corbanbrook/webgl-2d

Canvas 2D is hardware accelerated in Chrome, Firefox and IE9, is it not? But I think what you're saying is that WebGL can still be much faster. Google demo-ed at I/O this year, how when an animation is done in WebGL it can be 10x faster than in Canvas 2D.

I believe Angry Birds is done in WebGL, but also falls back to Canvas 2D for browsers (or computers) that don't support WebGL.

Chrome has it a bit hidden[1] as it seems to be a bit buggy. I haven't seen Firefox/Opera with this currently supported. But I believe it is a matter of time until all major browsers fully support hardware accelerated canvas2d by default.

I like that with projects like this you don't have to wait 2/3 months: you can use it now.

[1] http://www.browserscene.com/2011/05/google-chrome-adds-optio...

iOS 5 will accelerate Canvas 2D as well.

Is it bothering anyone else that the graphs seem to indicate performance regressions with newer versions of Firefox/Chrome?

requestAnimationFrame() is new to me. Sort of a setTimeout() but with the time being "when it is appropriate to draw a new frame". A much more polite way to handle animation in the browser, especially when there are multiple independent animations running.

A little article with shim code: http://paulirish.com/2011/requestanimationframe-for-smart-an...

Draft: http://webstuff.nfshost.com/anim-timing/Overview.html

I find it surprising to introduce a function intended for animation callback that doesn't seem to provide facilities for time handling. That is, the callback doesn't seem to be provided with the current time, and requestAnimationFrame() does not take a desired FPS as a parameter.

.. Sorry the spec does say the callback should be provided the time as an argument. It's just not being used in these examples.

The data here is a little odd to me. Sometimes Chrome 13 is much faster than Chrome 14, and vice versa. The same happens when comparing different browsers.

I guess it's possible there are such huge differences, but it's surprising to me.

My understanding is that between Chrome 13 and Chrome 14, they switched canvas backends. The new backend was a partial (perhaps even complete) rewrite that introduced some bugs and changed performance characteristics. I think the purpose of it was to introduce more pervasive hardware acceleration. They were originally going to roll out the new backend in Chrome 13, but they had to turn it off because it was too buggy.