[Public WebGL] Shaders, glReadPixels and speed

[Vladimir Vukicevic]

On 1/3/2010 9:00 PM, stephen white wrote:
> I was referring more to the step by step nature of needing to feed 
> variables through, which leads to this kind of analysis:
>
> Gregg Tavares <g.....@> writes:
>>> 1 call to for each matrix you want to pass to the shader (usually 1 
>>> to 4 matrices)
>>> 1 call for each color parameter ( for phong the minimum would be 2, 
>>> color
>>> and shininess though most phong shaders have 5, emissive, ambient, 
>>> diffuse,
>>> specular, shininess)
>>> 1 call to setup position vertices
>>> 1 call to setup normals
>>> If it's textured you'll need another call to supply UVs
>>> 1 call to finally draw the object
>>> and then possibly a few calls to restore GL state.
>>>
>>> That a minimum of 5 calls and in this case a maximum of 13 per 
>>> object, per
>>> frame. JavaScript is going to have a tough time doing that for more 
>>> than a
>>> few objects and keep 60 or even 30hz.
>
> Rather than having a custom engine like O3D, it seems less 
> controversial to add in a standard GL_ARB_geometry_shader4 so that 
> WebGL is capable of displaying and animating 3d graphics to an 
> equivalent level.
>
> The shaders have the vector and matrix functionality that is a painful 
> library in Javascript, so is there a way of pushing the code across to 
> that domain? Use a fragment shader and render vertex data to a texture?

Are the calls that Gregg outlined above actually showing up as a 
bottleneck?  If they are, that's a performance bug that I'm pretty sure 
we'll all be very motivated to fix; geometry shaders don't really 
replace much of that work, and emulating them in software and/or trying 
to do a bolt-on to GL ES seems like a bad way to fix these problems.  As 
Ken mentioned, the best thing to do is to send along some benchmarks 
showing bottlenecks that we can jump on.

For Firefox, we're moving to hardware compositing for WebGL in the next 
month or so (hopefully next few weeks actually, depending on when some 
patches land), and I have some patches in the queue that should 
significantly speed up all WebGL calls and the WebGL array types.  But 
again, any benchmarks/testcases showing problems would be very welcome.

     - Vlad

-----------------------------------------------------------
You are currently subscribe to pub...@
To unsubscribe, send an email to maj...@ with
the following command in the body of your email: