[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Public WebGL] GL_RENDERER string needed for performant apps

That's our use case

From: Boris Zbarsky
Sent: ‎14/‎01/‎2014 22:22
To: James Darpinian
Cc: Florian Bösch; public webgl
Subject: Re: [Public WebGL] GL_RENDERER string needed for performant apps

On 1/14/14 5:11 PM, James Darpinian wrote:
> The reason the UA string became a problem is because browsers exposed
> different APIs for the same features. Developers responded by writing
> multiple versions of their code, and then switching based on UA string
> (instead of feature detection like they should).

That's the previous incarnation of the UA string problem, 10 years ago.

The current one in the mobile space is quite different.  It's a problem
because sites assume all sorts of things like screen size and desired
web page layout based on the UA string, not because they're changing
which features they use.

> Developers will not need to
> write multiple versions of their code

Wait.  The whole point of the discussion I've seen so far is that people
want to use GL_RENDERER to decide whether to run particular code or
somewhat different code or not even try WebGL at all.  Not because the
API is different but because the implementation in the graphics hardware
is different in a way they care about (performance mostly, sounds like).
  Am I just completely misunderstanding the proposal?  If not, then I
don't understand your argument here...

> so doing the wrong thing and using GL_RENDERER for
> feature detection would actually be quite difficult.

The proposal, again if I understand it, is to use GL_RENDERER to decide
whether to use particular features, even if they're supported.  In the
end, that's what feature detection is for as well: deciding whether to
use particular features.  Basically, use of GL_RENDERER comes down to
"well, this GPU _says_ it supports this feature, but the support does
not meet our quality criteria, so we need to not use it anyway".  Again,
unless I'm completely misunderstanding the proposed uses?


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