15 comments

[ 0.26 ms ] story [ 40.5 ms ] thread
I recommend that you don't turn it up to 512 resolution on a macbook in firefox. =(
That's why you use Google Chrome. I turned it up to 512 and that particular tab got hosed but I could easily kill it. :)
Wow, that's mesmerizing.

I would love to see this on a multi-touch display. I wonder if you could make an iphone app like this. Maybe have a little paper boat that floats on the surface which you can't interact with directly but you have to use your fingers to change the flow of the water to shepherd the boat through certain obstacles?

If anybody wants to do this I'll donate my time to make the art :-P

Autodesk has an iphone app called "Fluid". Pretty much the same idea.
You can do all the multitouch stuff with javascript on the iPhone. No need for an app.
Definitely something that would benefit from the new Javascript "web workers" (worker threads). http://blog.mozbox.org/post/2009/04/10/Web-Workers-in-action
web workers don't have DOM access.
I doubt updating the UI is real processor-intensive. The worker threads would do the math without blocking the UI.
The actual issue is parallelising it appropriately -- realistically the best you can do (with this approach) is hoist computation into a worker (which i'm working on) and you get hit by data transfer costs at that point as workers do not allow any form of data sharing between threads.

I'm not sure if there is any way to feasibly improve threading of computation in a non-shared-state threading model.

Broken in Chrome on Vista Ultimate 32-bit.
Working in Chrome on Windows 7 32-bit.
It works much faster in Chrome than Firefox.
It's even faster on recent WebKit builds (the "official" editions with SquirrelFish).

Not too surprising, considering Oliver works on SquirrelFish ;)

more specifically still faster in chrome beta than firefox 3.5 beta on leopard