[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
- To: public webgl <firstname.lastname@example.org>
- Subject: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed
- From: Benoit Jacob <email@example.com>
- Date: Tue, 1 May 2012 11:22:40 -0700 (PDT)
- In-reply-to: <1909422100.310142.1335894092276.JavaMail.firstname.lastname@example.org>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- Sender: email@example.com
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 firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: