[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL performance...seems like I have no hardware acceleration?!?
On Thu, May 27, 2010 at 3:01 AM, Jonatan Wallmander <firstname.lastname@example.org>
Firefox (currently or used to) work like this which is probably what you're experiencing:
On 05/27/2010 05:27 AM, Steve Baker wrote:
Cedric Vivier wrote:
On Thu, May 27, 2010 at 10:18, Steve Baker<email@example.com
Well - it certainly behaves as if it's not hardware accelerated,
So it looks like we're either not running with hardware acceleration -
or there is some kind of software operation on the raster going on
that's crippling the frame rate.
Your results are surprising, are you sure Firefox is using hardware
acceleration on your setup ?
(you should see a message about failure to create a pbuffer in the
Canvas 3D: creating PBuffer...
Canvas 3D: ready
...and nothing else. So I guess that's OK. I actually tried turning
software rendering on via "webgl.software_render=true" in the
about:config page, when I do that, I don't get a valid context (probably
because I don't have Mesa installed). So it's pretty much certain that
I do have hardware acceleration turned on...it's just spectacularly slow
for some weird reason.
But then, what could WebGL possibly be doing to make glclear take so
much per-pixel time if the hardware is doing the work?
GPU Pbuffer -> RAM -> CPU software compositor -> RAM -> GPU
...which is why even a simple blit at high resolution is slow.
As a side effect this introduces vsync tearing issues when the
desktop lacks a compositor/isn't double-buffered/vsynced (win7 without aero, linux without compiz).
This will be fixed when/if the browsers move to a OpenGL compositor and that is the plan for firefox
(I lack information to draw any conclusions about chromium).
There's a GL-based compositor in chromium as well sitting behind a compile time flag. We'll soon make it available with a command-line flag and once we're satisfied with how it performs will enable it for good. The performance hit you get from read pixels will most likely disappear probably even before the 1.0 version of the spec is out.
Then the rendering would be done in an FBO,
and if the page lacks other elements to composit it will be 99.9% fast. Combined with the one-process-per-tab
architecture which firefox is also implementing (which chrome already has) there will be very little obstructing
the performance of a game (in theory).
Firefox devs are working on all this but I don't know status.
Chromium-latest-linux32 is also broken (just tested it), it hangs whenever opening a page.
I'm running the latest daily builds of
Yeah - I guess I should try that.
FireFox "minefield" - and I've double-checked that I have software
rendering disabled in the 'about:config' system. I'm running Linux on
one machine, WinXP on another and Windows-7 on a third - and getting
pretty consistent results on all three machines.
There is an ongoing refactoring of the rendering code in Firefox, this
might impact you if some of this has been pushed to Minefield daily
For instance, on Linux, _trunk_ cannot create a hardware-accelerated
WebGL context anymore without applying work-in-progress patch from
: https://bugzilla.mozilla.org/show_bug.cgi?id=565833 .
Maybe you should try running WebGL with latest Chromium to check if
you get same results or not.
Can't say what the windows/mac versions are like though.
This is my current opinion as well. However I have every belief it'll turn out good in the end.
Actually - I can live with poor frame rates for now - I just want to be
sure that they'll get back to something reasonable before I get to the
point of wanting to release my work in a few months time. If there is
some fundamental reason why these kinds of performance figures are
"normal" - then I guess I'll drop the idea of porting games.
A dream scenario would be great to have some kind of dev platform in the meantime - some kind of
nightly build that is at least performing and working well even if it compromises
some design goals - for us end users to tinker with. It'd be worth a lot for webGL having
good content when the implementations are stable. Just a thought.
You are currently subscribed to firstname.lastname@example.org
To unsubscribe, send an email to email@example.com
the following command in the body of your email: