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

Re: [Public WebGL] Proposed change to WebGL Event definition

On Mon, Dec 20, 2010 at 3:27 PM, Chris Marrin <cmarrin@apple.com> wrote:

On Dec 17, 2010, at 2:43 PM, Gregg Tavares (wrk) wrote:

> On Fri, Dec 17, 2010 at 2:34 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
> Sorry I didn't pay attention to this earlier
> Maybe this isn't important but I was hoping the webglcontextcreationerror event would let me distinguish between at a minimum 2 situations (I can think of more).
> #1) The browser does not support WebGL
> #2) The browser does support WebGL but the hardware is not up to it.
> Right now apparently the distinction is if I get the event then the browser supports webgl but the hardware is not up to it. Otherwise it wouldn't support the event.
> But then how do I distinguish that from #1?  In the #1 case I call getContext("webgl") and if it returns null then what?
>     canvas.addEventListener(
>       "webglcontextcreationerror",
>       reportThatBrowserSupportsWebGLbutNotYourHardware);
>   var gl = canvas.getContext("webgl");
>   if (!gl) {
> To answer my own question,
> I suppose I can do this
> if (window.WebGLRenderingContext) {
>   // browser supports WebGL

I don't think you can rely on that. There is nothing in the spec that requires the WebGLRenderingContext prototype to be publicly available. You don't need it for creation since getContext() does that. It is useful for type checking, but there is no text in the spec that requires it.

Currently we have conformance tests for this. I don't know what in the WebIDL or spec needs to change to ensure it but for example it's pretty useful to be able to do

if (tex instanceof WebGLTexture)


if (context instanceof WebGLRenderingContext) {
} if (context instanceof CanvasRenderingContext2D)
The browsers appear to all support the correct types for Canvas 2d objects. Why not WebGL objects as well?

I agree that there needs to be distinction between these cases. But I think we agreed that you can add the event listener, then call getContext(). If that returns a context, you're golden. If it returns null, then either the event listener would have fired (you're hardware isn't up to the task), or not (your browser doesn't support WebGL). Not the most elegant solution, but I think its passable.

That's the problem. The event handler is not allowed to fire until _javascript_ exits. Hence the example using setTimeout which seems a pretty round about way for this to work.