[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

On Tue, May 1, 2012 at 3:50 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Tue, May 1, 2012 at 1:22 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
>> 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.
> I think it would make more sense to put it on the context, because what it
> returns depends heavily on the context itself.  For example, if the GPU
> changes (eg. the window changes from one monitor to another), that can cause
> WebGL contexts to be lost; device properties like this are closely tied with
> that.
> I don't think it's any problem to create a context, test whether you want to
> use it, and then discard it if you decide that you want to use a 2D Canvas.
>> 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".
> This is nitpicky at this point in the discussion, but it should return an
> empty object, {}, not null, so you can say eg.
> "if(getDeviceAdvisories().slow)".
> A problem with "slow" is that its meaning changes over time, which has
> backwards-compat problems.  For example, suppose you have a system which is
> fast enough to not be considered "slow" by the standards of 2012; it works
> fine with web pages written in 2012.  However, in 2016 the device doesn't
> work well or at all with new webpages; it's slow by the standards of that
> year.  You want to flag the device as "slow".  However, there's a problem:
> pages written in 2012 still exist and are still used in 2016.  That system
> still works fine on those pages.  If you suddenly flag it as "slow", there's
> a huge chance you're going to break something that was working before,
> because that old webpage--which was working just fine--now thinks it's
> "slow", and changes behavior (to a lower-functioning 2d canvas
> implementation, or to a code path that doesn't work at all).
> This is a really hard thing to do in a way that's both forwards- and
> backwards-compatible...
>>  * The default is to expose no information.
> Not exactly--the default is to expose whatever information the browser
> thinks is useful.  "No information" isn't the default, it's just the
> simplest case.
> I point this out because for this to be useful, it would need to be enabled
> in browsers by default, not made into an option that defaults to off.  (I
> don't think disabling it by default is what you meant, it's just what
> "default is no information" sounds like to me.)
> On Tue, May 1, 2012 at 2:40 PM, David Sheets <kosmo.zb@gmail.com> wrote:
>> I propose using URIs for capability profile predicates.
> Using URLs for identifiers is almost always severe overdesign.  URLs should
> only be used for real resources that can be usefully fetched with some
> protocol, not as identifiers for concepts.

That's a nice personal opinion. It's my understanding that the W3C
strongly disagrees with your view in a large number of web standards.

'slow' is a valid relative URI reference. I am simply proposing a
default base URI inside of Khronos' URI namespace with properties
interpreted as URI references. This automatically gives us a way to
extend the result set of the host profile call without collision and
provides means to unambiguously refer to these properties (instead of
"the property called 'slow' in the object returned from
getDeviceAttributes() in WebGL 1.0").

That is, 'slow', when dereferenced, is actually
'http://www.khronos.org/registry/webgl/properties/slow' or perhaps
'http://www.khronos.org/registry/webgl/properties/2012/slow' and so

You yourself said

> This is a really hard thing to do in a way that's both forwards- and
> backwards-compatible...

and I have proposed the use of a ubiquitous web standard which solves
this ambiguity problem.

> Just use simple strings, with vendor prefixing if appropriate (even that's
> probably overkill).  It works just fine for extensions, which is a much
> larger and more complex set, as well as extensible things like <link> (which
> is simply maintained on a wiki referenced from the HTML spec).

It doesn't really work very well for either of those cases because it
assumes either no authority or a central authority (or special custom
knowledge). Extensions should be referenced by URI (and I will make a
proposal regarding this soon). <link> is much weaker than it should be
due to the aforementioned wiki and resulting confusion,
incompleteness, and disagreement over precise semantics.

We already have a global federated namespace the underpins the web.
Why don't we use it? It only takes the will of the standards body; the
technical infrastructure is already in place.


> --
> Glenn Maynard

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