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

Re: [Public WebGL] FF4 webgl doesn't work on ATI Mobility Radeon HD 4250

On Fri, Mar 11, 2011 at 2:28 PM, Chris Marrin <cmarrin@apple.com> wrote:

On Mar 11, 2011, at 1:32 PM, Gregg Tavares (wrk) wrote:

> On Fri, Mar 11, 2011 at 9:07 AM, <steve@sjbaker.org> wrote:
> > It would be nice if the browsers could optionally provide more detail
> > about the reason the context wasn't available.
> >
> > In my case if my app could get the information that I had an acceptable
> > video card but the driver version was too old and I'd need to update it --
> > I'd build that in to my app to provide better info for a user about how to
> > get a working version.
> I too would like that.  One way I try to deal with that is to redirect the
> user to http://get.webgl.org - which at least provides a central point for
> detecting, diagnosing and explaining to the end user why he's not getting
> any pretty graphics...and perhaps offering advice about what to do about
> that.  That web site has gotten a lot better recently - and it's always
> the first place I go when I have a machine that won't produce a webgl
> context.
> If they don't have webgl you should direct them to http://get.webgl.org
> if (!window.WebGLRenderingContext) {
>    // the browser does not know what webgl is
>    // present a link or redirect to http://get.webgl.org
> }
> If they DO have webgl but it won't initalize you should direct them to http://get.webgl.org/troubleshooting
> gl = canvas.getContext("webgl");
> if (!gl) {
>    // present a link or redirect to http://get.webgl.org/troubleshooting
> }
> There is no good reason for every application to have to handle this
> individually.

There is a good reason if a site wants to send users to branded pages to help with their troubles. They might also be in a walled garden or they think our landing pages are too garish or slow or something. The point is, landing pages are good to have, but we also need to provide authors with a good set of tools and let them go nuts.

I don't think we should encourage that though. If a large company wants to spend thousands of dollars tracking down troubleshooting info for every browser and platform combination and translating that into every language nothing is stopping them but most developers will be better served by just directing to those links which will ultimately take users to info relevant for their situation.
I agree with that; for the same reason, I think that the majority of websites will be better served by a localized string in webglcontextcreationerror, than by raw error codes.