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

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



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?

-Ken

-----------------------------------------------------------
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: