[Public WebGL] Re: [whatwg] Canvas.getContext error handling

David Sheets [email protected]
Fri May 6 17:09:45 PDT 2011


On Fri, May 6, 2011 at 4:25 PM, Glenn Maynard <[email protected]> wrote:
> On Fri, May 6, 2011 at 6:46 PM, David Sheets <[email protected]> wrote:
>> The proposed solution is to make the reference in the form of a
>> conditionally downloaded, centrally maintained diagnostic script that
>> lets users stay on an application site.
>
> This isn't a solution at all.  A remote script can't provide real
> diagnostics for installing WebGL, since a remote script doesn't have
> access to the necessary information: driver versions, GPU manufacturer
> and product, the browser's current GPU blacklist, and so on.

This is the same situation as with the current get.webgl.org site.

>> The alternative is that the small WebGL players use get.webgl.org and
>> suffer the UX and friction while the big WebGL players actively
>> maintain their own diagnostics (at considerable expense) for better UX
>> and lower friction. This harms adoption.
>
> This is the only way that can actually give a useful UI to end users
> for anything but trivial cases that can be detected browser-side (eg.
> checking whether WebGL interfaces exist and known browser version
> checks).

I am still talking about in-site detection. If browser vendors want to
implement diagnostics that is separate from in-site detection, great.
I'll believe it when I see it. Everything I have said still holds for
small vs. large WebGL application authors.

> However, this isn't an "alternative".  They're not mutually exclusive,
> and browsers will always have the option of doing this.  (I'm not
> really sure what you're suggesting "harms adoption" here, either.  It
> seems like you're saying that major browsers giving better diagnostic
> UI would harm adoption.)

Again, I am not saying anything about browser vendor diagnostics. The
alternative here is between:

A the coder-on-the-street linking to get.webgl.org and every
commercial enterprise rolling their own in-site diagnostics or giving
up on WebGL as glitchy and broken and choosing a proprietary 3-d
solution

OR

B encapsulating the get.webgl.org logic and providing a simple means
to use it without pointing users off-site

I am saying that A harms adoption. It seems increasingly unlikely that
in-browser diagnostic interfaces will be standardized before
Molehill/Silverlight make all of this irrelevant. Browser vendors can
of course implement these systems and hopefully will. Simply telling
application authors to wait for browser vendors and send their users
to get.webgl.org seems like a great way to discourage adoption.

We have the means to provide a pretty good experience /today/. The
major limitations are the opacity of get.webgl.org and the intentional
removal of hardware information by browser vendors. Browser-level
diagnostics are great. Protecting user privacy is great.
Unfortunately, the browser vendors have removed diagnostic information
but not provided their own diagnostic systems. This is bad for
adoption as diagnosing problems is well beyond most users.

David Sheets

> --
> Glenn Maynard
>

-----------------------------------------------------------
You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------




More information about the public_webgl mailing list