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

Re: [Public WebGL] Firefox 4 and blacklist reporting

On Wed, Mar 30, 2011 at 2:15 AM, Gregg Tavares (wrk) <gman@google.com> wrote:
> Unfortunately it's convoluted to use webglcontextcreationerror because as
> far as I know no one has implemented it.
> You have to do something like this
> if (!window.WebGLRenderingContext) {
>   // the browser has no clue what webgl is
>   ...
> } else {
>    try {  // need a try here because of Firefox
>      canvas.addEventListener("webglcontextcreationerror", getError, false);
>      ctx = canvas.getContext("webgl");  // and experimental-webgl
>    } catch (e) {
>    }
>    if (!ctx) {
>      // since we don't know if the browser implements
> webglcontextcreationerror yet
>      // we need to setup a timeout in case it doesn't send one.
>      setTimeout(reportTrouble, 1);
>    }
> }
> err = ""
> function getError(event) {
>   err = event.message;
> }
> function reportTrouble() {
>   alert("Your WebGL had trouble initializing: " + err);
> }
> Worse, AFAIK there's nothing in the HTML spec that says that you have to get
> the webglcontextcreationevent before the timeout. I suspect all browsers
> will send it immediately after javascript returns control to the browser but
> there's no guarantee. You could set the timeout to a larger number in the
> hope that you'd never have a browser that would send that first or maybe you
> don't care, you'll just get no error message.
> Maybe we should revisit that part of the spec. Maybe getContext should throw
> and we should define the exception object it returns. That would make it a
> lot less convoluted. I forgot why we didn't have it throw originally.
> Something from the canvas spec?

I don't remember precisely the reason for not throwing an exception in
this case, but here's some background I do remember.

There were extensive discussions in the working group on what happens
if two getContext() calls are made against the same canvas element,
passing different context attributes. We considered throwing an
exception for the second call if the attributes didn't match those
from the first call. After several code samples were posted, we agreed
on the current behavior of not throwing an exception, returning any
previously-created context, and always returning a non-null context if
doing so was at all possible.

The canvas spec states that null is returned (without throwing an
exception) in a couple of cases: if the context type is unsupported,
or if another incompatible context has already been created against
the canvas. Is the situation where the context couldn't be created
(because the card was blacklisted) materially different from the
context type being unsupported? It could be argued both ways.

Are there any interactions with lost context? What if we attempt to
fetch a WebGL context when the graphics card is in a "lost device"
state but will soon recover?

I do think that it would make the program logic simpler if an
exception were thrown upon context creation error, though this would
force all users of WebGL to add a try/catch around their getContext()
call. I think this sort of change would be feasible in a spec update.


> -g
> On Tue, Mar 29, 2011 at 7:12 PM, Mark Callow <callow_mark@hicorp.co.jp>
> wrote:
>> On 30/03/2011 01:08, Gregg Tavares (wrk) wrote:
>> On Tue, Mar 29, 2011 at 1:29 AM, Mark Callow <callow_mark@hicorp.co.jp>
>> wrote:
>>> ...
>>> I thought get.webgl.org/troubleshooting would try the context creation
>>> again and display the error string from webglcontextcreationerror, if
>>> any?
>> No, it should not because many cards and browsers crash on context
>> creation which means going to that page would not help them.
>> In that case the public wiki needs sample code for handling
>> webglcontextcreationerror. I think it should be included in webgl-utils.js.
>> Regards
>>     -Mark

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl