[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





----- Original Message -----
> 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.

I have no experience with that whatsoever, so no opinion. I just want to make one point: any solution that relies on parsing strings is probably bad. I'm not saying that the URIs approach relies on parsing strings, but I do see strings in the above paragraph, so I'm saying that just in case.

Even if somehow that particular kind of string parsing can't be gotten wrong by applications, it remains that any string parsing will be more complicated to use than just

  if (advisories.slow)

Cheers,
Benoit  

> 
> 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
-----------------------------------------------------------