

Liquid particles in HTML5 - DeusExMachina
http://spielzeugz.de/html5/liquid-particles.html

======
gb
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....](http://blog.inspirit.ru/wp-
content/uploads/fluidsolver/Main.swf) \- 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).

~~~
pmjordan
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.

~~~
chipsy
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.

~~~
pmjordan
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)

~~~
phoboslab
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.

------
spielzeugz
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)

<http://www.craftymind.com/guimark2>

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.

Fyi, did some comparisons a while ago, <http://spielzeugz.de/html5/compare>

Cheers, Dan

------
thehodge
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

~~~
ashleyw
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.

Unless you prefer 'Web 3.0'? :)

~~~
mseebach
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.

------
RyanMcGreal
What really impresses me is that even when the pointer is outside the frame,
the particles still cluster as close to it as the border allows.

~~~
thegoleffect
That only works while your cursor is inside the browser window though. Outside
the browser, it stops following you.

------
superduper
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.

~~~
99miles
It's chunky for me too in Firefox, especially the 'letter' version. Pretty
cool, but it's definitely still got a ways to go.

------
elblanco
this interface would make for a challenging game, "guide the mass of particles
through a machine, loosing as few to wall collisions as possible".

