Re: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed

[David Sheets <kosmo.zb@gmail.com>]

On Tue, May 1, 2012 at 11:22 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
>
> Hi,
>
> We've discussed several times before, and rejected, proposals to expose device/driver info to content. Here's another, different proposal.
>
> 1. add a new function --- let's call it getDeviceAdvisories() --- that can be called without a WebGL context, as it will be meant to be called before getContext. For example, it could be a method on the window object.
>
> 2. getDeviceAdvisories() returns a JS Object, which may be null. By default, the browser will return a null object, which should be interpreted as "nothing special to say about this device".
>
> 3. Now if browser developers get reports from application developers that a certain device is causing them trouble, browser vendors can quickly update this object to add some properties that are characteristic of this device. For example, if a driver is known to have very slow VTF, the object returned would have a boolean property,
>
>    vtf_slow = true
>
> We could also imagine
>
>    slow = true
>
> for software-only WebGL renderers, as many apps that have a good Canvas2D or even non-Canvas fallback would prefer it over a slow WebGL implementation.
>
> It should even be possible to update it within 24 hours without requiring a software update, as is typically done for blocklist updates. I imagine that JSON would be a convenient format for browsers to store this information.

I propose using URIs for capability profile predicates.

If you dislike the idea of using absolute URIs, I propose using
relative URI references like "#vtf_slow" and "#slow" with a default
base URI at khronos.org.

This same host profile facility is probably useful to a wide variety
of nouveau browser APIs. Integrating with an extant standard or host
profile system would be preferable to creating a new profile system. I
believe most logical assertions regarding Web hosts, resources, and
clients should attempt to use the federated namespace structure of URI
that is now ubiquitous.

David

> 4. Whenever the device is no longer a major cause of trouble, e.g. if a work-around has been implemented since, the device advisory can be dropped.
>
>
> Some reasons why I like this proposal while I was against the vendor/renderer/version strings:
>
>  * Any exposed information is directly useful. By contrast, UA-string-like solutions rely on applications to correctly parse them and correctly make use of that information, which is a well-known cause of artificial portability problems on the Web.
>  * The default is to expose no information.
>  * If a browser always returns null, that's totally cool, apps will just assume no driver issue then.
>  * The amount of information exposed is minimal (I don't think we'd expose more than 2 bits given that the OS name is already exposed, compared to about 10 bits for the renderer/version strings).
>  * The information exposed pertains to specific testable issues, so it could be obtained fairly easily anyway by running some WebGL code exposing the corresponding issue.
>
>
> Why do I care about this now? Partly from conversations with Web developers, and partly because browsers are getting software fallbacks for WebGL (Chrome already has it now), and I am concerned that silently falling back to software rendering for WebGL is going to break applications that have a WebGL and a non-WebGL renderer and make the naive assumption that if WebGL is available then it is necessarily the better choice.
>
>
> Opinions?
> Benoit
>
> -----------------------------------------------------------
> 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:
> unsubscribe public_webgl
> -----------------------------------------------------------
>

-----------------------------------------------------------
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:
unsubscribe public_webgl
-----------------------------------------------------------