WebGL: 80,000 particles
minimal.be
minimal.be
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 [more RAM, if nothing else!] and you might need to reconsider the disadvantages of native apps in favor of all the advantages that centrally hosted applications offer [no Apple fee, no pirating, continuous deployment, cross-platform, etc, etc.].
I long for a vibrant open-source project that builds quality widgets and elements for people to use inside this framework. Let's not pretend jQuery mobile et. al. are anywhere close.
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.
A more clever way to code that animation would be to pass the mouse position to the GL shaders that would compute themselves the particle positions, and I think modern GPUs are very optimized for that kind of stuff.
Please don't be too rude, cause it was my first WebGL experiment.
I'd be pretty surprised if vertex texture fetch wasn't supported though. It works on basically all hardware from the PVR SGX on up. Unified shaders are pervasive on both phones and desktops. I did find this, though, which implies that for a while that the browsers weren't properly exposing support:
http://stackoverflow.com/questions/4349389/webgl-texture-acc...
I don't think that's an option in ES2 or WebGL. I'd love to be proven wrong!
While running this page on Firefox on Ubuntu it showed:
render busy 7%
bitstream busy 0%
blitter busy 10%
Vertex Shader Invocations: 1520152/sec
Pixel Shader Invocations 59160531/secIf 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 dev.)
It's not nearly as efficient as this demo, but it's at least a game. There are at least a dozen areas I could fix up to prevent the GC from going nuts if I was so inclined, but it works fine for most people.
With Flash you could render +300000 particles years ago: http://www.unitzeroone.com/labs/alchemyPushingPixels/
"On my OsX toy the difference between flash on browser and standalone is insane. 200 000-300 000 particles is pretty much the maximum until it won’t run smooth anymore. I wonder if this is memory related thing? or what? Who knows? Someone from Adobe might… Well anyways. Here’s the same thing exploding 1.4 million particles in 1920×1200 resolution with smooth 60fps."
Interesting behavior.
On that other JS demo mentioned in a sibling comment my puny 9400m runs at a steady 30fps at 100k with 7~10% CPU on Safari. The same goes for some non-browser pyopencl [0], which uses about 10% CPU. I seem to be hitting a sort of bottleneck here as ramping either up to 200k or using the Flash realtime demo brings FPS down to about the same level. The Flash one though, uses between 20 and 60% CPU and mostly hovers around 30%. Whatever that means.
[0] http://enja.org/2011/03/22/adventures-in-pyopencl-part-2-par...
here's another fast one in webgl: http://iacopoapps.appspot.com/hopalongwebgl/ reading the source, it has 280000 particles.
Now-a-days it's pretty much standard to use two floating-point off screen textures to store, update, and draw the particles completely on the GPU. This way, you can get 1M+ particles easy.
Preserving state directly on the GPU makes it so you can get up into the millions of particles (depending on the videocard of course): http://mikecann.co.uk/projects/HaxeWebGLParticles/
if you don't let the particles catch up w/ your mouse (and trace circles around them) the gather up in one place and turn white, resulting in some spectacular 'explosions'
I actually think this could become a game; maybe you show the player a pattern and then he tries to recreate it... or something among those lines.
http://www.ea.com/auditorium-iphone
Some of the levels are pretty hard!
Using Google Chrome 19.something on Ubuntu, with open source radeon driver.
Same error.
Very small bug I thought I'd mention: If you resize the browser window the center of the particles no longer tracks the mouse pointer location but rather appears to be offset by an amount depending on the resize that happened. W7/C19
http://www.html5rocks.com/en/tutorials/webgl/million_letters...
Also, a paper about pure-GPU implementation:
If you want to benchmark the same page with 80000 particles, try this link : http://minimal.be/lab/fluGL/index80000.html
Is there a way to start experimenting with webgl using python?
(the WebGL animation is part of an interactive installation)