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