Re: [Public WebGL] GL_RENDERER string needed for performant apps

[Benoit Jacob <bjacob@mozilla.com>]

On 14-01-14 04:59 PM, Brandon Jones wrote:

On Tue, Jan 14, 2014 at 1:45 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

I sincerely doubt that anything like this can be removed after being added and after pages start using it...

For typical web features this is certainly true. I feel that this case may be an exception because of the way it's been implemented as an extension.

• You have the query the extension explicitly from a function that is documented to return null if the requested feature is not supported.
• That function WILL return null on all browser currently, including Chrome.
• It's a good bet that it will continue to return null for a decent number of users for a while, even if everyone jumped on the bandwagon today, simply because these things take time to propagate.

It would be ludicrously bad for an app to query the extension and start using it without checking to ensure the extension was returned first. Such a usage is clearly a violation of the most fundamental principles of good OpenGL/WebGL practices, and it's doubtful that anybody caught doing so will have the technical competency to build something of much merit.

If I understand correctly, the above explains why we will not have the problem that Web pages absolutely require GL strings to run.

But they might still require GL strings to run /well/. If they rely on GL strings for more tuning than necessary, then they will be poorly tuned on clients not exposing accurate GL strings.

This is similar to Websites using the UA string to determine whether the client is mobile. These Websites "work" everywhere, but are give a very poor user experience on mobile browsers that weren't recognized as such.

That's why I believe that the availability of GL strings on some UAs will result in a user experience degradation on other UAs.

Benoit

--Brandon