[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Public WebGL] Shaders, glReadPixels and speed



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.

* 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.

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

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.

--
 steve@adam.com.au

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