Liquid particles in HTML5 | Hacker News Reader

Liquid particles in HTML5

spielzeugz.de

116 pointsDeusExMachina26 comments

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.

Yes, I suspect its the implementation of the canvas object thats the bottleneck here.

An implementation of sub-objects (eg. sprites) on the canvas along with a dirty area only rendering algorithm would go a long way to bridging the gap.

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.

Actually the Flash version is done by drawing at a pixel level too (although some of the filter effects are indeed done by the player). The source is here: http://code.google.com/p/in-spirit/source/browse/#svn/trunk/...

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.

http://www.ponticstar.com/projects/burning-words/

try set the font size to 100

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.

A "little" slow meaning 2-3 fps maximum, at least on my iPad :)

A "little" slow on my android as well ;)

Pretty damned fast on my Sony laptop. Go figure.

It runs extremely smoothly on chrome 5.0 and a 1.6GHz atom, using about 90% of the CPU. No noticeable jerkiness, smooth motion, and so forth.

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

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

This is using the Canvas tag which is new to html5

At least he didn't say it was pure CSS3.

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

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'? :)

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.

Here's the relevant section of the HTML5 spec...

http://www.whatwg.org/specs/web-apps/current-work/multipage/...

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.

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

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.

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

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

Reply on news.ycombinator.com