Firefox 40.0: 1000 Bunnies at 12 FPS
Firefox 40.0: 10000 Bunnies at 12 FPS
Firefox 40.0: 20000 Bunnies at 12 FPS
Firefox 40.0: 30000 Bunnies at 12 FPS
Chrome 44.0: 1000 Bunnies at 60 FPS
Chrome 44.0: 10000 Bunnies at 60 FPS
Chrome 44.0: 30000 Bunnies at 30 FPS
Why this extreme difference between Chrome and Firefox?about:config in Firefox says "GPU Accelerated Windows: 0/3" so I guess it is somehow not using the GPU. Although then Im surprised it can render 30k bunnies at 12 FPS. On the other hand, it says "WebGL Renderer: NVIDIA Corporation -- GeForce GT 630/PCIe/SSE2". So I guess it's using the GPU. Also I would expect this WebGL demo to not even run without FF using the GPU. Strange. Any ideas?
The issue seems to be in some kind of limbo, with many users reporting that the compositing mode doesn't even make a difference.
- Chrome 44: 60 FPS constant
- Firefox 39: 49 FPS
- Firefox 40: 59-60 FPS
- IE 11: 10-12 FPS, very poor.
The FPS counter doesn't appear on my smartphone (falcon, CM12.1 Browser), but i would estimate the performance is at about 10-15FPS at the default number of sprites, let alone the full 300 000.
- Chrome 44: 100 FPS
- Firefox 40: 60 FPS
- IE 11: 10 FPS
I don't think that FF is limiting itself to 60 FPS as I have a 144Hz monitor and other WebGL demos can render at frame rates well in excess of 60 FPS in firefox.
FF nightly 2015-08-31 24fps
chrome 44.0.2403.157 (64bit) 26fps
MS Edge 20.10240.16384.0 30-33fps
(i7-4770k igfx)
The differences weren't visually very apparent. None of the browsers seemed to have periodic GC lag, which in the past certainly was an issue.
I'm curious: which browser did you develop this with/optimize on?
- Chrome 44: between 10 and 20 fps.
- Firefox 40: *very long load time* constant 14 fps300000 sprites
fps: 59-60
os: Linux
browser: Chrome 44
cpu: i7-3930k
gpu: GTX 970
driver: Nvidia 346.47
The hash worked here! http://haxor.xyz/demos/bunny-mark/#500000
For mobile, only touching and adding bunnies (with possible bugs for iOS)
Some extra info. I'm updating the [x,y] on JS and the rest is 1 drawcall in the WebGL side.
It also seems ripe for tuning; it appears to leak a dom object every frame and churn through memory at a pretty epic rate :) (at least per chrome dev tools)