[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.
In fact, I agree with you now. But please let me add some background here:

A while ago, I measured OpenGL context creation to be really slow, often above 100 ms. Further testing showed that it's only the first OpenGL context creation that is that slow, and subsequent context creations are typically in the 5 -- 10 ms range. That is still a slow operation. And one may still be concerned about the cost of the first context creation.

But, we also know that we want to allow async context creation, and an idea that's been proposed is to immediately create a context in lost state, then asynchronously create the OpenGL context, and dispatch a webglcontextrestored event when it's created.

That would remove the reason not to put getDeviceAdvisories on the WebGL context: users concerned about performance could simply do

var advisories = canvas.getContext("webgl", {async:true}).getDeviceAdvisories();

So let's put getDeviceAdvisories on the context and keep focus on adding async context creation asap.
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)".
Good point; that was my intention and I didn't notice that returning null was disallowing that.

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.
Good point, but by "slow" I didn't mean "this machine is slow compared to other machine". Instead, I meant "this feature is slow compared to other features that you might prefer to use instead, on this given machine".

Indeed, the application doesn't get to choose the machine it runs on, but it does get to choose the approach it takes to rendering on a given machine.

That's why it seems reasonable to me to call software WebGL rendering "slow".
  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).
With my concept of "slow", we would never downgrade a given system to "slow" just because it's gotten old relatively to the current market.

Basically, we would only call "slow" implementations that do a large part of rendering in software. Besides software renderers, we could call old Intel chips up to and including the GMA 3000 "slow" because they don't accelerate vertex shaders.

For very specialized features that are not used by a majority of applications, and are very slow compared to other operations on some systems, it is worth introducing specialized flags. For example, VTF on the Geforce 6 and 7 should be advertised with a vtf_slow flag.

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 meant that even in browsers that sometimes return non-{}, in a majority of cases, {} will be returned. The only other return value that will represent more than 10% of the market will be {slow=true}. The {vtf_slow=true} case will represent some old cards, and (as hard as that is to phrase diplomatically) we could have a {stability_concerns=true} flag for certain OpenGL implementations that we couldn't quite decide to blacklist.

So if a browser vendor wants to always return {}, that's cool: it will be indistinguishable from other browsers in the majority of cases.

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.)
Of course! I didn't mean it should be disabled by default.


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