[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed
- To: Benoit Jacob <bjacob@mozilla.com>
- Subject: Re: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed
- From: David Sheets <kosmo.zb@gmail.com>
- Date: Tue, 1 May 2012 12:40:16 -0700
- Cc: public webgl <public_webgl@khronos.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dUJfOb3ShUPOt6JQhuzNP0/155qE2gV4KPVP3Fm5A0E=; b=proGfilKxFIZd7zFn5t5MLszaNltQZdbpF9uww/QpWdffIH2yF30ACC6qrmreipiCH B06BSO7LDRfTXi79Q//gERPrxdnYYHivOME9RStn84ffc5DHcLO2J2P9i9+AAi7VmCbO S/OhZZgr1gKqBld3riH1qOuCeJQ4vyimBzt5bi6I01LtVTpNXaULtWApu6O6QxmpzAtl M7mCeT8prxyrsM9ELzAEnvaBFxfw7GI/peY+WgRAyndaZzHdfGszp1XXLOYrkpIZRHh5 /yccBrjRljq1xOnpPwQgBeS0UnKfM1mIBd1bOwcQIbmOOyQ72Vets7jEfck8q+ftCayI ntIA==
- In-reply-to: <68851291.338775.1335896560640.JavaMail.root@mozilla.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <1909422100.310142.1335894092276.JavaMail.root@mozilla.com> <68851291.338775.1335896560640.JavaMail.root@mozilla.com>
- Sender: owner-public_webgl@khronos.org
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
-----------------------------------------------------------