[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL performance...seems like I have no hardware acceleration?!?
----- "Steve Baker" <firstname.lastname@example.org> wrote:
To test, I wrote a really minimal application - it sets up matrices, it
clears the screen and renders a few simple objects and uses
setTimeout("draw()",1) to try to get the best framerate I can. I'm
getting like 10Hz. :-(
nasty, I tossed out all of the 3D rendering and did nothing but clear
the screen. Doing this test at a number of different canvas sizes, I get:
800x600 : 35Hz.
200x200 : 90Hz.
100x100 : 180Hz.
8x8 : 180Hz.
Commenting out the clear-screen and doing no OpenGL calls at all in my
main loop still gets me 180Hz - so I guess I'm CPU-limited at that frame
I believe you are (sadly) hitting one of the biggest problems in our various implementations -- for each frame, they all essentially do a glReadPixels() and then composite the frame into the browser's window using GDI or another mostly-software compositor. As far as I know, currently only Safari/WebKit on Mac uses a hardware accelerated path end-to-end. Minefield/Firefox, Chrome, and Safari on Windows (not sure if it even does WebGL yet) all do the ReadPixels bit. This explains why you're seeing such atrocious performance as your canvas size goes up. :-)
We're all working on fixing that, though. If you're using a recent Firefox nightly (from Monday's onwards), you can use an experimental extension that'll open the current page in a new window which will use hardware compositing. You can install it here: http://people.mozilla.com/~vladimir/misc/makegofaster.xpi . Once you install and restart, go to about:config and search for opengl, then double click "mozilla.layers.prefer-opengl" to set it to true. Then, open your page, and select "Faster!" from the Tools menu. There are lots of (mostly known) bugs right now with rendering HTML content here, which is why this stuff isn't on by default yet, but it's helpful for testing. You may need to resize the window to get an initial draw to happen. I've also only tested this on Windows; not sure if it'll work on OS X.
I've got a simple little benchmark at http://people.mozilla.com/~vladimir/misc/ctest3d.html that just calls clear() as fast as it can; it also uses a postMessage() trick, as setTimeout only allows 10ms timeouts at the fastest -- or rather, it used to; not sure what the rule is now, it might be unlimited with only deeply nested timeouts getting the clamping. Using postMessage gets around this limitation. On my laptop, with a maximized window, I get around 12fps (at 1680x1050, minus window borders and such) using the software/readPixels path, and about 180fps in the maximized compositing window case. There's still additional performance work to be done, but removing the readback bottleneck is key for making any reasonable size (or fullscreen) WebGL apps possible.