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

Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings



>> Steve explained in an earlier email how ACCELERATION_STATUS may not be
>> very useful,
>
> Right, I should have read his email more carefully the first time, I've
> replied to it now. I claim that his particular example is best handled by
> the WebGL implementation.

So who will be the organization that pro-actively looks for problems like
the faked vertex-texture support - for EVERY graphics card, every
CellPhone...with EVERY driver version on EVERY OS and in EVERY browser -
and decides which to fix and which not to fix...and to do this in a timely
manner?

That's an immense on-going task requiring a lot of funding.

What's more, when you do find a problem, how will you ensure that every
end-user gets a browser update?

When an application author finds a bug with a particular setup - he can
probably work around it right then and there and have a new web page up
within hours...but only if he can make the fix happen apply only to that
particular setup.

But worse still - to extend the vertex-texture example further:

* In my application, I have GIGANTIC vertex shaders - they do a ton of
heavy work - pushing them into CPU-software is a disaster.
* In some other application, there might be a tiny vertex shader that
reads the vertex texture and does almost nothing else.  Even though
shaders are dumped into CPU-side software when we use a vertex texture,
it's still much faster than working around the problem using JavaScript in
the CPU.

In my case, the internal-to-WebGL fix would be to intercept the glGet that
queries the number of available vertex textures - and return zero instead
of one.

But the other guy would find that disasterous - he'd much prefer for WebGL
to do nothing at all.

So which does the WebGL fixing-graphics-hardware-bugs organization decide
to do?

  -- Steve



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