[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 Wed, May 2, 2012 at 1:47 PM, Gregg Tavares (勤) <gman@google.com> wrote:
> On Wed, May 2, 2012 at 11:53 AM, Ashley Gullen <ashley@scirra.com> wrote:
>> I think this is a great idea and I'm desperate for something like this.
>>  Our engine implements both a WebGL and Canvas 2D renderer, and currently
>> the Canvas 2D renderer is never used in Chrome 18 due to Swiftshader.  I am
>> keen to fall back to Canvas 2D instead of using Swiftshader but there is no
>> way to do that.
> That's a little bit of an exaggeration. You can certainly choose Canvas 2D
> at anytime. You run a small benchmark and switch.

You include a small open source benchmark script which shims
getHostProfile() with
{"http://helpfulpeople.com/webgl/is_canvas2d_faster": true|false}

This is a declarative rather than imperative interface as many of the
most useful web interfaces are declarative.

"If you can do it with data, don't do it with code."

> You can give the user
> options like nearly every Window's game in existence. (screen size,
> rendering features, texture detail, etc...)

Options that could be eliminated by better automatic environment
detection is bad UX.

> I'm not arguing against the proposal. I just don't think it should be
> decided by arguably false points.

Whether it is done now by this body or in 2014 by another, this sort
of feature will exist. Analogous interfaces already exist in many,
many diagnostic and profiling libraries and other new web APIs. Many
libraries provide ad hoc feature detection.

WebGL is in particularly dire need of this sort of _standard_
capability information due to the complexity of the underlying

Khronos has the chance to lead the entire World Wide Web here by
introducing an extensible host profile API. Even if no 'privileged'
host information (like make, model, or implementation) is exposed via
this API today, the interface should be in place and returning a
well-typed {}.

I'm sure there are other groups who have encountered this sort of
issue. Perhaps someone knows of a similar system implemented

The discussion over the specific properties to expose is irrelevant.
Properties will be exposed. They will be useful.

The WebGL WG isn't architecting one stand-alone standard. The WebGL WG
is doing city planning and local governance for the future of
cyberspace. As such, fundamental questions like "what are the types
allowed across this interface?" and "what is the canonical data
schema?" are far more important than whether the WG decides to make a
predicate called "slow" or "really_slow" and what precisely that

Without deciding a single property to provide, the WG can opt to
create a new method call ("getDeviceProfile"? "getHostProfile"?) that
returns a JS hash-like object, {}.

JS hash-like objects have two type parameters, key and value. To
support JS implementations that only provide keys as strings, the type
of the key must be some sort of string. I propose the following:

1. This string is a relative URI reference with a base URI of
2. For every relative URI reference under the default Khronos base
URI, an identical value is inserted in the {} profile with the
resolved absolute URI. Now we're having our cake and eating it, too.
And that's no lie.

The type of the values can be any JavaScript object at the most
general. The allowable specific JavaScript types used as objects of
the profile predicates is itself a property of the predicate. This
type constraint may be decided by the party with authority over the
URI of the predicate.



>> I don't think "slow" is a good term to use because it seems to me to be
>> subjective.  Suppose someone has a weird system with a fully-hardware 2006
>> graphics card and a modern 8-core 2012 CPU.  Swiftshader might be faster
>> than the GPU.  Which is "slow"?
>> I'd rather one of these terms, or both:
>> "no_gpu": no graphics-specific hardware chip is present.  This does not
>> mean "software rendering".  A GPU using part software rendering still counts
>> as a GPU.
>> "blacklisted": a device is present but was blacklisted (not used) due to
>> known issues.  A Swiftshader WebGL context would say "blacklisted", because
>> it *could* have used a GPU, but didn't because the driver was unstable or
>> whatever.  In that case I'd want to ditch the blacklisted WebGL context and
>> fall back to Canvas 2D.  Alternatively a message could be issued indicating
>> the user needs to upgrade their driver or hardware.  Considering Firefox's
>> stats show something like 50% of users have a blacklisted driver, I think
>> it's essential to expose this information.
>> Note they don't mean the same thing, if you have no graphics hardware then
>> no_gpu is true and blacklisted is false (a non-existent graphics card is not
>> blacklisted), whereas a blacklisted GPU sets no_gpu to false and blacklisted
>> to true.
>> If there is the possibility of multiple GPUs with different advisories
>> then I suppose they should be associated with the context that you actually
>> got.
>> I would then myself define 'slow' as:
>> var slow = advisory.no_gpu || advisory.blacklisted;
>> which I think is what most people's definition really is, but is not
>> enforced or suggested by the browser, it's the developer's interpretation.
>> Some people have expressed concern that this will make the weird system
>> with the 2006 graphics card and 2012 CPU run slower than if it had used the
>> CPU.  My answer is: I don't care.  If there is a GPU there I want to use it,
>> because it is probably more power-efficient than the CPU, which is important
>> on mobile.  Also, a good software renderer like Swiftshader will burn up all
>> your CPU cores, which is a little obnoxious - lots of people complained
>> about how Flash would always "use 100% CPU" for a simple advert when looking
>> at a simple web page; people notice if they have a noisy fan; other apps
>> struggle for CPU time; in apps like games, logic is fighting with rendering
>> for CPU time, so there's less parallelism.  So in short you're system is
>> designed wrong (why install a graphics chip which has the overall effect of
>> *slowing down* graphics rendering??) and I would say the software rendering
>> is still "wrong" even if it's faster because it's *inefficient*, which is a
>> slightly different meaning to "slow".
>> Ashley Gullen
>> Scirra.com
>> On 2 May 2012 16:47, Benoit Jacob <bjacob@mozilla.com> wrote:
>>> ----- 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
>>> -----------------------------------------------------------

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