No idea what you mean. It's just as fast, if not faster, for me. I don't know what that one does (haven't looked at the code), but it's cloth interaction is more powerful so it's probably just an interaction difference. I liked a softer interaction, but moving the mouse fast if you want to blow it up.

EDIT: I shouldn't have said "no idea". There is one reason I can think of -- this uses WebGL, so if you have a bad card or drivers this might be slower. My algorithms might be more precise too, I don't know the other code.

EDIT2: A coworker just mentioned that I should turn off antialiasing (it's on by default) and that should help a lot of machines. Also optimized WebGL a few other ways.

This is relatively new (early 2013 retina macbook pro 15", MacBookPro10,1, 2.7 Ghz, 16GB Memory), so I would think WebGL would work in both places ...

I don't think WebGL is used with the original, since it was working just fine on my eeepc with linux (which does not do WebGL, last I checked). This new one barely works in chrome on windows on this T420 though.

I don't know what the cause is in my case, maybe WebGL on this thinkpad is really slower than CPU rendering on an Atom?

I'm using the exact same rig and testing same version of Chrome, and they seem the same. We're really just comparing WebGL to canvas. Note that I had to use WebGL because with asm.js, the cloth gets so dense that canvas couldn't handle it.

Not having any issues in latest FireFox nightly / OSX / Retina MBP, am running at 225x110 or something like that. Nice job!

It seems like the cloth in this version has much higher tension so it doesn't respond as much when you pull on it.

You need Firefox Aurora or Nightly (which will be Firefox 22 and 23) for asm.js support, without which the demo will be several times slower than it could be. (I have no idea whether it should match the speed of the original in browsers that don't support asm.js or not.)

This isn't exactly right. First, the demo starts with a really tiny cloth and then scales it up until your system starts slowing down. Second, he's comparing the same dimensions with asm.js and non-asm.js code, and they should be equivalent in browsers without asm.js (in fact, that style of code is usually a tiny bit faster because it's hitting all the optimized parts of javascript).