any idea why i get the JS error "requestAnimationFrame is not defined" when I run the HTML page on my local system. Same browser (firefox 12)) renders the online-like just fine.
As i understand this method is part of the browser's JS api. So, why is it not defined if I run it "locally"?
WebGL: 80,000 particles
41–50 of 85 posts
Re: WebGL: 80,000 particles
#42It's actually 30,000 particles, not 80,000. See the source: "numLines = 30000". If you set a breakpoint at that line (28), then you can edit the variable in the console to whatever you want. You can make it smaller without setting the breakpoint, but any higher results in a "attempt to access out of range vertices" error. I can get it to ~40,000 on my iMac's 6970m 2GB without noticeable slowdown (this is w/ Chrome 20…
Vertex indexes are 16 bit. It's probably set to 30000 for a very good reasons.
Re: WebGL: 80,000 particles
#43circling the particles to try and trap them is fun, makes me feel a bit like one of those machines they try and trap plasma in :)
Re: WebGL: 80,000 particles
#44The most impressive bit of this is that it it keeps under 20% CPU on my Mid-2010 MBP [Chrome 19]. It's hard not to imagine another cyclical shift towards browser centric development, away from rich client apps, when you have Chrome pulling off tricks like this. Things that would've seemed impossible in 2008, the last time everything was moving to the browser. Give Apple/ARM/Intel/Samsung a few more cycles in mobile […
CPU utilization is the wrong metric. Your CPU is mostly idle because it's feeding a tiny set of commands to the GPU each frame, and then idling waiting for user input and/or vsync. The GPU is running full-tilt, but unfortunately there's no good OS-level tool to show that.
One of the reason CPU utilization is so low is that this is a demo. Most of the "logic" is just a straightforward computation of the mouse position, and the particle coordinates are all figured out from that in the shader engines. Real apps and games have real data that needs to be crunched.
(Edit: I just checked the source, the particle positions are actually computed in Javascript, the shaders are just straight rendering. And I don't see anything particularly clever about the implementation, it's just a bunch of array accesses. V8 is doing an amazing job on this.)
But broadly, you're right: the need for highly optimized native code to drive a modern GPU has mostly disappeared. A javascript interpreter (well, V8) is more than good enough.
Re: WebGL: 80,000 particles
#45any idea why i get the JS error "requestAnimationFrame is not defined" when I run the HTML page on my local system. Same browser (firefox 12)) renders the online-like just fine. As i understand this method is part of the browser's JS api. So, why is it not defined if I run it "locally"?
Have you downloaded all the files? requestAnimationFrame is defined in http://minimal.be/lab/fluGL/RequestAnimationFrame.js
Re: WebGL: 80,000 particles
#46any idea why i get the JS error "requestAnimationFrame is not defined" when I run the HTML page on my local system. Same browser (firefox 12)) renders the online-like just fine. As i understand this method is part of the browser's JS api. So, why is it not defined if I run it "locally"?
Have you downloaded all the files? requestAnimationFrame is defined in http://minimal.be/lab/fluGL/RequestAnimationFrame.js
thanks; i missed the import. I only remember that the method also exists in the JS api itself. did not think that there might be a wrapper around with the same name :-)
Re: WebGL: 80,000 particles
#47From this tweet, it seems it is actually 30000 particles: https://twitter.com/boblemarin/status/204943143798448129
Yeah it is: http://news.ycombinator.com/item?id=4008846
When I wrote that experiment (nearly one year ago), I started with 80000 but finally went for 30000 because it was smoother on my laptop. I just forgot to change the title when posting (it was a long ago, and I wasn't expecting it to get much attention).
If you want to benchmark the same page with 80000 particles, try this link : http://minimal.be/lab/fluGL/index80000.html
Re: WebGL: 80,000 particles
#48It's actually 30,000 particles, not 80,000. See the source: "numLines = 30000". If you set a breakpoint at that line (28), then you can edit the variable in the console to whatever you want. You can make it smaller without setting the breakpoint, but any higher results in a "attempt to access out of range vertices" error. I can get it to ~40,000 on my iMac's 6970m 2GB without noticeable slowdown (this is w/ Chrome 20…
Vertex indexes are 16 bit. It's probably set to 30000 for a very good reasons.
Please, check my post below for the truth about the numbers
http://news.ycombinator.com/item?id=4009469
Re: WebGL: 80,000 particles
#49Earlier quoted context omitted.
That demo gets about 19 fps on my machine, whereas the WebGL demo appears to be getting close to 60, so that seems to be scaling pretty similarly. Also keep in mind that the demo you linked to uses Alchemy, which is C/C++ compiled to AVM2, so for WebGL to be getting roughly equivalent performance is pretty damned impressive.
Actually the 'math' was done using alchemy, the shader was pixelbender http://www.adobe.com/devnet/pixelbender.html However the example was flash then (3 years ago) vs webgl now. This is flash now; a version with 1.4 million particles using the new molehill http://www.simppa.fi/blog/1_point_4_million_particles/
Well, that's looking like about 3 fps; it's a lot more particles, but it's also a lot slower, so I don't know how that balances out.
Re: WebGL: 80,000 particles
#50Earlier quoted context omitted.
Have you downloaded all the files? requestAnimationFrame is defined in http://minimal.be/lab/fluGL/RequestAnimationFrame.js
thanks; i missed the import. I only remember that the method also exists in the JS api itself. did not think that there might be a wrapper around with the same name :-)
AFAIK, no browser uses the name 'requestAnimationFrame'; everyone prefixes it still.