This is a good illustration of how much slower JS/canvas is than AS3 at the moment, unfortunately.
For comparison: http://blog.inspirit.ru/wp-content/uploads/fluidsolver/Main.... - a much more complicated algorithm running with more particles and additional visual effects, and it runs more smoothly (although admittedly this does use 10-15% more CPU on my machine, still I don't believe the same thing implemented with canvas would run nearly so well).
I suspect this is less of an issue with the language (implementation) and more an issue with the fact that canvas is just that: a pixel buffer, whereas Flash allows higher-level geometric constructs which may be rendered more efficiently (batching, only redrawing dirty areas, etc.).
I also wonder if the occasional jerkiness is caused by the fact that setInterval() makes no hard guarantees for call frequency. To compete on animations, HTML canvas will realistically need to provide a guaranteed redraw callback that runs at the same rate as the system VSync.
Even Flash doesn't offer hard guarantees of smooth, artifact-free animation. It has a fairly sophisticated timing model, and you can improve your chances with the "direct" wmode (vs. the default "normal"), which makes Flash draw "on top of" the browser instead of "inside" it, but it eventually comes down to the specific platform and drivers, I think.
I realise that at that level of abstraction a "guarantee" as such is pretty much impossible, but we don't really want to be writing interrupt handlers in user space. Flash presumably goes to more effort of keeping a consistent framerate, whereas JS's setInterval()'s "not guaranteed" is basically a get-out-of-jail-free card for the browser.
A "I'm done with this frame, please call this function when I can start drawing the next one" function would be a great first step. (As would dealing sanely with off-screen canvases)
Well, you can do a setTimeout with just 1ms delay or use window.postMessage when it's available. I must admit though that it is kinda counter intuitive how "swapbuffer()" is called only implicitly when your top level function finishes. But it doesn't work too bad.
I found that the GC is usually not a problem in any browser when you want to animate something smoothly in <canvas>. Plugins in FF (like Firebug or the Echofon Twitter Client), or things like an AJAX request however can result in stuttering animations.
Can you elaborate your statement about "(...) dealing sanely with off-screen canvases"? Do you mean things like double/tripple buffering?
Edit: For the record: the particle animation runs extremely smooth in Safari on my 2 year old Macbook Air. As far as I can tell, Safari on OSX currently has the most "direct" and efficient way to draw Canvas elements.
From my experiences with canvas it seems the calling the drawing methods is the major bottleneck for this sort of thing. Minus the visuals I would guess the JS on V8 would run comparably to the AS3.
Yes, it was a little slow on my iPad. Couldn't get the AS3 demo to load.
I guess the question we need to ask is "will html5 get faster?". For example, will we see 2x or 3x improvements in the next few years? Java, for example, was initially much slower than C++. Now it's quite competitive.
Hi guys, I did that demo mentioned above.
It's true that Flash is significantly faster. While ActionScript and JavaScript are almost on par in recent browser versions the main difference is the rendering performance. Here's a very good explanation (see the last paragraphs)
It's about retained vs. immediate mode rendering: Flash is frame-based, on each frame code is executed first, display changes are collected, then rendered. With JavaScript each change is rendered immediately which is less efficient, especially with multi-core CPUs.
As for the iPad, this demo here runs slowly cause the iPad is slow. ;-) Native apps run smoothly cause they're hardware-accelerated, but in the browser you notice the difference.
Am I missing something or is this just Liquid particles in HTML + JS. The HTML5 tag seems to be getting knocked about quite a bit really... someone said HTML5 is the new AJAX and I am starting to agree
It's using Canvas, so yes it's HTML5. And even though it's using Javascript, I've always considered that to be the tool you use to communicate with the HTML API. The same goes for CSS to some extent, too.
Anyway, the average joe needs a buzzword to sum up all the new browser advancements. "HTML5" isn't that bad, at least it makes sense.
It's not just a buzzword. Many of the new features of HTML5 assumes scriptability, so it's perfectly reasonable to refer to HTML5 without mentioning JS.
I think we need to accept that the 'HTML5' name will be mis-used to mean 'HTML5 + CSS3 + JS'. It certainly is easier that naming all 3 component technologies and IMO its acceptable as those browsers that support HTML5 typically support some degree of CSS3 as well (and of course JS).
This is a great example of how much better the JS engine is in Chrome or Safari than Firefox. FF just seemed to chug for me when the particles really started moving.
For comparison: http://blog.inspirit.ru/wp-content/uploads/fluidsolver/Main.... - a much more complicated algorithm running with more particles and additional visual effects, and it runs more smoothly (although admittedly this does use 10-15% more CPU on my machine, still I don't believe the same thing implemented with canvas would run nearly so well).