[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL performance...seems like I have no hardware acceleration?!?
Vladimir Vukicevic wrote:
> 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. :-)
Thanks! That's pretty much what I've deduced through experimentation.
I get typical hardware-type fill rates - plus this fairly constant
5Mpixel/sec overhead that depends only on the resolution of the screen
and not how many times I overwrite it or my shader complexity.
> 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.
Woohooo! Awesome! I'll give it a spin.
For now though, it's enough to know that it's getting fixed and that I
don't have to worry too much about my poor high-res frame rates. I'm
still at the stage of rewriting perfectly good C++ code into nasty
on the CPU - also shifting code into the server where it can still be
C++ where that makes sense.
> 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.
Yeah - that's excellent. OK - panic over! Back to trying to remember
to type 'vec4' instead of 'float4'...and suffering the consequences of
an untyped programming language! :-)
Incidentally - just in case too few people have already said this:
IMHO, WebGL is the most important technology advance in years - I can't
thank you guys enough for putting it together. When this hits the web
in a production FireFox build and full-blown photo-realistic 3D can be
delivered through a web page...it's going to be revolutionary.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: