7 ms·

Liquid particles in HTML5

116 points by DeusExMachina 16y ago

thehodge 16y ago
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
- amitt 16y ago
  This is using the Canvas tag which is new to html5
- ElbertF 16y ago
  At least he didn't say it was pure CSS3.
- al_james 16y ago
  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).
- ashleyw 16y ago
  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 16y ago
    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.
- pohl 16y ago
  Here's the relevant section of the HTML5 spec... http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html http://www.whatwg.org/specs/web-apps/current-work/multipage/...
gb 16y ago
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.swf 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).
- pmjordan 16y ago
  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.
  - al_james 16y ago
    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.
  - chipsy 16y ago
    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 16y ago
      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)
RyanMcGreal 16y ago
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 16y ago
  That only works while your cursor is inside the browser window though. Outside the browser, it stops following you.
elblanco 16y ago
this interface would make for a challenging game, "guide the mass of particles through a machine, loosing as few to wall collisions as possible".
superduper 16y ago
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 16y ago
  It's chunky for me too in Firefox, especially the 'letter' version. Pretty cool, but it's definitely still got a ways to go.
spielzeugz 16y ago
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 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 http://spielzeugz.de/html5/compare Cheers, Dan

116 points by DeusExMachina 16y ago

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

amitt 16y ago
This is using the Canvas tag which is new to html5
ElbertF 16y ago
At least he didn't say it was pure CSS3.
al_james 16y ago
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).
ashleyw 16y ago
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 16y ago
  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.
pohl 16y ago
Here's the relevant section of the HTML5 spec... http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html http://www.whatwg.org/specs/web-apps/current-work/multipage/...

gb 16y ago

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

pmjordan 16y ago
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.
- al_james 16y ago
  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.
- chipsy 16y ago
  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 16y ago
    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)

RyanMcGreal 16y ago

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 16y ago
That only works while your cursor is inside the browser window though. Outside the browser, it stops following you.

elblanco 16y ago

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

superduper 16y ago

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 16y ago
It's chunky for me too in Firefox, especially the 'letter' version. Pretty cool, but it's definitely still got a ways to go.

spielzeugz 16y ago

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 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 http://spielzeugz.de/html5/compare Cheers, Dan