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

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


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.

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.


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