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

Re: [Public WebGL] Shaders, glReadPixels and speed

On 04/01/2010, at 5:24 AM, Kenneth Russell wrote:
What browser and operating system are you using? Safari on Mac OS X

Mac OS X 10.5, which probably lacks the hardware composition in the browser (despite being nightly). It is good to know that all browsers are moving towards hardware compositing to address this bottleneck.

needed but the raw speed of sending down floating point numbers via
WebGLFloatArray is already pretty good.

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...@google.com> 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?


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: