[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
JavaScript and refactoring stuff to put more load onto the GPU and less
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.

  -- Steve.

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: