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

David Sheets [email protected]
Fri May 6 15:46:02 PDT 2011


> Maybe. Of course you know if that server ever goes down then every page
> using that jquery directly would go down as well.
> Since we're only talking about a script that helps users who CAN'T run webgl
> it doesn't seem worth the trade off that 60% of your users and climbing have
> to download a script they don't need (ie, WebGL works for them so they don't
> need the script)

The script can be dynamically loaded when WebGL fails. The loading
stub would be static and quite small.

The key is that web developers would like a reference to a
troubleshooting resource that reflects the current state of WebGL
support.

The current solution is to make that reference in the form of a web
site that users must be linked to. These users will consume
get.webgl.org resources and will potentially have left the application
site or given up on WebGL altogether.

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.

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.

Why isn't get.webgl.org open source? Who are its current maintainers?
Why don't we produce a little conditional include snippet for authors
to use?

>>
>> - Remi
>>
>> ________________________________
>> From: "Gregg Tavares (wrk)" <[email protected]>
>> Sender: [email protected]
>> Date: Fri, 6 May 2011 12:30:20 -0700
>> To: Mikko Mononen<[email protected]>
>> Cc: Glenn Maynard<[email protected]>; Kenneth Russell<[email protected]>; Tim
>> Johansson<[email protected]>; Cedric Vivier<[email protected]>; Mark
>> Callow<[email protected]>; <[email protected]>
>> Subject: Re: [Public WebGL] Re: [whatwg] Canvas.getContext error handling
>>
>>
>> On Fri, May 6, 2011 at 2:17 AM, Mikko Mononen <[email protected]> wrote:
>>>
>>> Ideally I would like to include a script from http://get.webgl.org,
>>> add a div to my webgl fault page, call init() with div id, and make
>>> the script do it's magic to populate the div with similar content that
>>> you get currently when you visit the page. That way the script could
>>> be always up to date, and I could give instructions directly on my
>>> sites fault page.
>>
>> There's no way get.webgl.org can handle the traffic for every WebGL page
>> on the planet including a script.
>> Just detect and send them there. That way only people for whom webgl is
>> not working will make it there and that number should get smaller and
>> smaller over time.
>>
>>>
>>> In our experience, we loose users at each step that needs to be done
>>> to resolve a problem. I'll check if we track on how many users fail
>>> webgl and how many of them actually tries to seek help.
>>>
>>>
>>> --mikko
>>>
>>>
>>> On Fri, May 6, 2011 at 10:13 AM, Gregg Tavares (wrk) <[email protected]>
>>> wrote:
>>> >
>>> >
>>> > On Thu, May 5, 2011 at 11:34 PM, Mikko Mononen <[email protected]>
>>> > wrote:
>>> >>
>>> >> On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard <[email protected]> wrote:
>>> >> >
>>> >> > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell <[email protected]>
>>> >> > wrote:
>>> >> >> It sounds like my earlier objection may have caused an impasse.
>>> >> >
>>> >> > Well, we're waiting for a response on whatwg.  There's always a
>>> >> > response, but it can take a while (overburdened spec editors, I
>>> >> > assume).
>>> >> >
>>> >> >> To clarify, the reason for the objection was the following. If the
>>> >> >> GPU
>>> >> >> is
>>> >> >> blacklisted, or some rare and unexpected error happens during
>>> >> >> OpenGL
>>> >> >> context creation, then it is important to be able to communicate
>>> >> >> that
>>> >> >> fact clearly to the developer, and from there to the end user.
>>> >> >
>>> >> > I know what you're saying, but to interject here: hopefully the
>>> >> > common
>>> >> > case for displaying errors won't be from the developer to the end
>>> >> > user, but from the browser directly to the end user.  (They aren't
>>> >> > doing this at all yet.)
>>> >>
>>> >> As a developer I have to disagree with the idea of browser directly
>>> >> talking to the user. IMHO This is different situation that a missing
>>> >> plugin.
>>> >>
>>> >> Currently the situation is that a lot of the folks coming to a webgl
>>> >> site can indeed see the content (in our case I think it is something
>>> >> like >60%). A great deal of the rest of users can be encourage to
>>> >> upgrade to a more fresh browser to make things work. That leaves us
>>> >> about 10% of users who either have old or weird os/driver combination.
>>> >> Those people need to be handled with developers support, because it
>>> >> generally is too complicated for them to triage the problem
>>> >> themselves, or it is too complicated to write comprehensive guide how
>>> >> to fix things*.
>>> >>
>>> >> There is no way my mum could understand what to do if she gets "Cannot
>>> >> initialize webgl" alert box when entering a home planner site. If
>>> >> simple request of upgrading a browser on developers site cannot fix
>>> >> the problem, then the user needs to be channeled to the developer
>>> >> support, and in that case the developer should be able to have as much
>>> >> information as possible (such as the messages explained below) so the
>>> >> the support can explain the user why the problem exists. Most of the
>>> >> time the answer will be "you have too old computer/os", but it is nice
>>> >> to be able to tell that in person, if that is the way the company
>>> >> wants to handle support.
>>> >>
>>> >> *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I
>>> >> do not dare to direct people there. Any change to be able to embed the
>>> >> script to your own site?
>>> >
>>> > What do you need fixed and we'll get it fixed.
>>> > It would be bad IMO for developers to put this on they're own site
>>> > because
>>> > they are unlikely to update it as new browsers, pages and platforms
>>> > appear.
>>> > It's also unlikely that most devs
>>> >
>>> >>
>>> >> > FWIW, I don't have any strong opinion either way on this.
>>> >> >  Personally,
>>> >> > I suspect the errors for the real uncommon cases (that is, anything
>>> >> > except "GPU blacklisted", "GPU/drivers insufficient" or "browser
>>> >> > doesn't support WebGL at all, I think) will probably not give very
>>> >> > useful error messages anyway.  It'd be nice to get error messages
>>> >> > like
>>> >> > "D3D surface creation failed: error code", "WebGL not supported;
>>> >> > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia
>>> >> > driver", since that would give developers a way to give at least a
>>> >> > bare amount of support to their users, but I doubt browsers will
>>> >> > ever
>>> >> > expose that level of detail.  (They don't even expose a real
>>> >> > GL_VENDOR.)
>>> >> >
>>> >> > --
>>> >> > 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
>>> >> > -----------------------------------------------------------
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Mikko Mononen, Software Engineer
>>> >> http://tinkercad.com - Solid modeling for artists & makers
>>> >>
>>> >> -----------------------------------------------------------
>>> >> 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
>>> >> -----------------------------------------------------------
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Mikko Mononen, Software Engineer
>>> http://tinkercad.com - Solid modeling for artists & makers
>>
>
>

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