[Public WebGL] Shaders, glReadPixels and speed

stephen white [email protected]
Sun Jan 3 04:51:59 PST 2010


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.

--
  [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:




More information about the public_webgl mailing list