[Public WebGL] Shaders, glReadPixels and speed

Kenneth Russell [email protected]
Sun Jan 3 10:54:39 PST 2010

On Sun, Jan 3, 2010 at 7:51 AM, stephen white <[email protected]> wrote:
> I am finding that WebGL has a per pixel performance that is amazing, but a
> per item performance that is very slow. The speed between the vertex and
> fragment shaders is unhampered, but things bog down in two main areas:
> * Transferring graphics back to the browser instead of drawing directly to
> screen. This makes a full screen 30x30 textured sphere slower than the same
> thing in Flash set to wmode=opaque. WebGL needs an equivalent wmode.

What browser and operating system are you using? Safari on Mac OS X
currently has the advantage of hardware accelerated compositing, but
all browser vendors are working on adding this, and it will eliminate
the glReadPixels currently needed to put WebGL on the screen. Adding a
wmode=opaque will be a temporary workaround which we don't want to
have to support forever.

> * Javascript performing matrix math operations then feeding it to the card
> variable by variable. The maths is optimised by the JIT, but the bridging
> cost is too large to help by having a C based implementation.

Could you please provide a test case which demonstrates the
performance problem? If you are finding that all of your time is spent
in uniformMatrix4fv calls, then you should be seeing the same
performance issue in C.

I can only speak for Google but we have already done some optimization
of data transfer from JavaScript to WebGL. More work is certainly
needed but the raw speed of sending down floating point numbers via
WebGLFloatArray is already pretty good.

> PROPOSAL: WebGL needs to specify a geometry shader API, with a fallback
> software implementation as a requirement.

I don't think a requirement of a software fallback is viable. As far
as I can tell the entire vertex and geometry shader path would have to
fall back to software, and this would kill performance. In a future
revision of the WebGL spec we could consider having a capability bit
which would allow the use of geometry shaders on capable hardware, but
I don't think that we should emulate the functionality.


> I know geometry shaders are not in OpenGL ES, however there is a increased
> emphasis on the need for geometry shaders as a result of interfacing to
> Javascript.  C level code can manage with vertex/fragment shaders alone as
> the CPU will be fully utilised. Javascript does not have that luxury,
> therefore it needs geometry shaders.
> Geometry shaders can be mostly implemented with vertex/fragment shaders, so
> the overhead would be minimised on platforms without hardware support. The
> flexibility of geometry shaders also forms the basis for writing hardware
> accelerated scenegraph engines, which would be WebGL's answer to Google's
> O3D and their amazing island.
> --
>  [email protected]
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:

You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list