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

Re: [Public WebGL] Extension proposal: WEBGL_lose_context



On Dec 8, 2010, at 2:56 PM, Kenneth Russell wrote:

> On Wed, Dec 8, 2010 at 1:11 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> 
>> On Dec 8, 2010, at 11:25 AM, Kenneth Russell wrote:
>> 
>>> On Wed, Dec 8, 2010 at 10:42 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>> 
>>>> On Dec 7, 2010, at 1:45 PM, Adrienne Walker wrote:
>>>> 
>>>>> Hi-
>>>>> 
>>>>> Now that the extension registry is live, I'd like to propose an
>>>>> extension to give both app and browser developers the tools to test
>>>>> lost context events.  As it stands now, these are difficult to test
>>>>> because many platforms don't have lost context events and additionally
>>>>> there's no way to programmatically force the loss of a context from
>>>>> Javascript.  It'd also be nice to get a conformance test in for this
>>>>> part of the WebGL spec.
>>>>> 
>>>>> I've attached a draft of this extension to this email.  Feedback welcomed.  :)
>>>> 
>>>> As I've mentioned before, I don't think debugging tools should be in the spec, or even in the registry. I think it's fine to do this sort of thing using the extension mechanism. But I don't think we should standardize it.
>>> 
>>> The WebGL extension registry is supposed to be a central location for
>>> documentation of extensions, even vendor-specific ones, so that
>>> developers know where to go to find out what might be supported.
>> 
>> Right, but the proposed extension has a WEBGL_ prefix, makes it normative. That's the part I disagree with. I think it's great that this site can be the repository of vendor specific extensions. But they need to be marked as non-normative. It would also be helpful to have an implementation table for vendor extensions.
> 
> What do you mean by normative here? The only distinction I see is
> whether the extension is expected to be implemented only by a single
> vendor or multiple vendors. It is perfectly legal for a WebGL
> implementation to not support any extension, even one with a WEBGL_
> prefix. If that isn't clear then I should probably update the foreword
> in the extension registry.

Yeah, that sounds right. The only distinction of WEBGL_ is that it has been ratified by some committee (presumably us) and everyone agrees on its functionality.

But I still don't think we should have a WEBGL_ extension for this functionality.

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