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

Gregg Tavares (wrk) [email protected]
Fri May 6 12:30:20 PDT 2011


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110506/635eb674/attachment.html>


More information about the public_webgl mailing list