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

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

On Thu, Oct 21, 2010 at 11:16 AM, Chris Marrin <cmarrin@apple.com> wrote:
> On Oct 19, 2010, at 10:22 AM, Kenneth Russell wrote:
>> On Sat, Sep 4, 2010 at 6:57 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>> On Sep 3, 2010, at 10:08 PM, Cedric Vivier wrote:
>>> On Sat, Sep 4, 2010 at 09:40, Kenneth Russell <kbr@google.com> wrote:
>>>> On Fri, Sep 3, 2010 at 10:16 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>>> I've revised the event section (5.14). Please review.
>>>> Sorry for not realizing this before, but the "NOT_AVAILABLE" status
>>>> code seems pretty useless, because if the web browser is so old that
>>>> it doesn't support WebGL, then it definitely won't support delivery of
>>>> the webglcontextcreationerror event.
>>> NOT_AVAILABLE "WebGL is not implemented or not enabled in this browser"
>>> I think the current meaning is confusing  (and indeed useless).
>>> IIRC the original planned intent for this status code, meaning should be
>>> something like :
>>> "WebGL is currently disabled or temporarily unavailable because of high
>>> resource usage by other tabs/programs."
>>> I think that's another status code. Perhaps reasons for failure are:
>>> - WebGL is not implemented (the event will never fire)
>>> - WebGL is disabled by the browser
>>> - WebGL is disabled by request of the user
>>> - Hardware is insufficient for running WebGL content
>>> - System is unable to run WebGL content because of other system constraints.
>>> Maybe it is a bad idea to have status codes. There could be many more
>>> reasons for not being able to use WebGL content. So maybe we should do as
>>> Ken suggests and only have a status message. That way the user agent can put
>>> any necessary recommendations into the string. The browsers would have L11N
>>> issues, but that is probably manageable.
>>> The unfortunate thing is that, if you don't have WebGL support at all, this
>>> event will never fire. You will simply get a null return from getContext().
>>> You' have to set up a timer and if it fires without any event being
>>> generated you know you don't have WebGL. That's a hack.
>>> I think the right way to handle that is to add a media query for WebGL.
>>> We've made a proposal to add media queries for CSS animations, transitions,
>>> and transforms. These are all supported in WebKit today. It would be easy to
>>> add one for 'webgl'. You can run the query from JS and know you don't have
>>> WebGL without having to call getContext(). But the really nice thing about
>>> media queries is that you can use them in CSS style sheets. If WebGL is
>>> missing you can style the page differently for, for instance, not take up
>>> the space for the WebGL canvas.
>>> So the proposal is to get rid of statusCode and add a media query for
>>> 'webgl'. I will talk to dino, who is pushing the media query extensions
>>> spec, about this as well.
>> Resurrecting this thread. I would like to remove the status codes from
>> WebGLContextEvent for the reasons I cited earlier. Are there any
>> objections to my doing so?
> None from me

I've removed the status codes from the WebGLContextEvent interface.


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: