The original (http://codepen.io/stuffit/pen/KrAwx) feels much more responsive (when feeding the same dimensions -- 114,53 -- as what your version uses), tested on Firefox 19.0.2 and Chrome 26.0.1410.65
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.
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.
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).
Just installed Nightly to test this out. It doesn't work. Just sits there blinking "Seeing how much your system can handle..." with no growing cloth in the background.
Opened up FireBug; the console had the following error at line 18 of renderer.js:
That means your browser doesn't have WebGL available. If you're on Nightly, that probably means your GPU is blacklisted. Type about:support into your address bar to see details.
You can get an exception from any canvas or WebGL API in cases where a driver is misbehaving (or, worst case, you have hit a browser bug).
You gotta wrap that stuff in try/catch (at least the getContext call, as a minimum). I don't think this is spec compliant, but I've seen it in Firefox, Chrome and Opera under various configurations.
Has anyone noticed that if you edit trace("Floating point literals are typed as double: " + 1.1 / 2) on lljs.org's demo to become trace("Floating point...are typed as double: " + 1.0 / 2.0) you get an answer of 0 instead of 0.5?
LLJS may not be ready for prime time, so compiling crap is probably just going to produce more crap.
Verlet.js is a physics engine written in javascript [0]. It was posted and discussed on HN a few days ago [1]. OP didn't write it, but probably understands it very well.
I didn't use the aforementioned verlet.js physics engine, but that's basically what this is. Verlet integration is a simple way of modeling forces. If you are referring to the actual js code, it's asm.js-compatible javascript, which you can read more about here: http://asmjs.org/
For me the cloth dimensions in Firefox go up to 122, in Nightly and Aurora go only to 85 and the lines of the cloth looks blurred. (Win8, latest NVIDIA driver)
"drag" is a misnomer then. It's like that so that you can play with the cloth some before destroying it. The interaction probably could be better though.
