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

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



Looks good to me, and nicely solves the "give more info if we have to return null".  It might be nice to add a status code that says something like "isn't available, might be soon" and then another for "became available" -- I'm thinking of the case where the browser wants to query the user if they want to allow WebGL.

    - Vlad

----- Original Message -----
> Currently the spec shows two event interfaces: WebGLContextLostEvent
> and WebGLContextRestoredEvent. Other Event generators in HTML tend to
> use a single Event object with many event types. For instance, there
> is a MouseEvent object with event types like "click", "mousedown",
> "mouseup", etc.
> 
> I propose we change the spec to have a single WebGLContextEvent object
> with 3 event types:
> 
> contextlost - The rendering context has lost its state.
> 
> contextrestored - The rendering context state can be restored.
> 
> contextcreationerror - An error occured when an attempt was made to
> create the context
> 
> The IDL would be similar to the existing objects, with error
> information added:
> 
> interface WebGLContextEvent : Event {
> // Status codes
> const unsigned short CONTEXT_LOST = 1;
> const unsigned short CONTEXT_RESTORED = 2;
> const unsigned short NOT_AVAILABLE = 3; // WebGL is not supported or
> not enabled
> const unsigned short NOT_SUPPORTED = 4; // Graphics hardware does not
> support WebGL
> const unsigned short OTHER_ERROR = 5; // Some other error occurred
> when creating context, details in statusMessage
> 
> readonly attribute WebGLRenderingContext context;
> readonly attribute unsigned short statusCode;
> readonly attribute DOMString statusMessage;
> 
> void initWebGLContextEvent(DOMString typeArg,
> boolean canBubbleArg,
> boolean cancelableArg,
> WebGLRenderingContext contextArg,
> unsigned short errorCodeArg,
> DOMString statusMessageArg);
> };
> 
> The contextlost event type would always have a statusCode of
> CONTEXT_LOST and contextrestored would always have a statusCode of
> CONTEXT_RESTORED. But both of these events can have a statusMessage
> which gives more details. I've included status codes for the two most
> common reasons a context could not be created and then a catch-all. I
> don't think we should go too far down the path of defining error
> codes. Many are platform specific and can be returned as OTHER_ERROR
> with a statusMessage.
> 
> Comments?
> 
> -----
> ~Chris
> cmarrin@apple.com
> 
> 
> 
> 
> -----------------------------------------------------------
> 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:
-----------------------------------------------------------
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: