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

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

Glenn Maynard