Re: Issue 74526 in chromium: WebGL getUniformLocation slow in Chrome (vs other browsers)

[chro...@googlecode.com]

Updates:
Summary: WebGL getUniformLocation slow in Chrome (vs other browsers)
Status: Available
Cc: gm...@chromium.org nd...@chromium.org sch...@chromium.org
Labels: Mstone-X Stability-Performance

Comment #4 on issue 74526 by hbr...@google.com: WebGL getUniformLocation
slow in Chrome (vs other browsers)
http://code.google.com/p/chromium/issues/detail?id=74526

Thanks, glad you were able to work around. I'm updating the title of the
bug, we'll keep it open to fix when we have fewer pressing issues :)

[chro...@googlecode.com]

Comment #5 on issue 74526 by g...@google.com: WebGL getUniformLocation slow

in Chrome (vs other browsers)
http://code.google.com/p/chromium/issues/detail?id=74526

It's common OpenGL knowledge that all glGet calls should avoided during
rendering and only used during setup. Even in normal OpenGL glGet calls are
extremely slow.

glGetError, glGetUniformLocation, glGetUniform, glGet<anything> as well as
glCheckFramebufferStatus

"glGet" calls are slower on Chrome. That is because Chrome is multi-process
and doing a glGet call means we have to stop and synchronize those
processes. On the other hand, in general we're able to take your single
threaded JavaScript WebGL program and ship a lot of the work over to a
second process. That means on a multi-core machine Chrome is able to take
advantage of 2 cores for your app where as other browsers can currently
only use 1 so if you code your WebGL following normal OpenGL best practices
you should run faster on Chrome than any other browser.

That said, we still have a few flow control issues to work out until we are
faster in every case but for example the WebGL Aquarium runs at 60hz on my
I7 MacbookPro in Chrome 11 with 500 fish. On FF4 I get only 33hz, On WebKit
I get around 50hz.

Some of that speed difference is because Chrome effectively uses 2 cores
where other browsers use 1.