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

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



Generally looks good, but the names of the events need to be prefixed
with "webgl", because these event names are going to be passed to the
Canvas during addEventListener and need to be scoped so that they
don't collide with other context types (present or future).

-Ken

On Fri, Aug 20, 2010 at 9:57 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
> 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: