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

Gregg Tavares (wrk) [email protected]
Fri May 6 13:34:32 PDT 2011


On Fri, May 6, 2011 at 12:46 PM, Rémi Arnaud <[email protected]> wrote:

> Google is hosting jquery and other scripts for the universe, maybe they can
> be convinced to host a webgl script?
>

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)



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


More information about the public_webgl mailing list