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

Re: [Public WebGL] WebGLContextAttributes

On Wed, Dec 23, 2009 at 3:48 PM, Chris Marrin <cmarrin@apple.com> wrote:
> On Dec 23, 2009, at 2:07 PM, Tim Johansson wrote:
>> On 12/23/09 3:36 PM, Kenneth Russell wrote:
>>> On Wed, Dec 23, 2009 at 3:13 AM, Philip Taylor<excors@gmail.com>  wrote:
>>>> On Wed, Dec 23, 2009 at 1:54 AM, Kenneth Russell<kbr@google.com>  wrote:
>>>>> The WebGLContextAttributes interface currently uses DOMStrings for the
>>>>> values passed to the NameSetter and returned from the NameGetter.
>>>>> Should these be type "any" instead? Currently creating such an object
>>>>> would be unnatural in JavaScript:
>>>>> gl = c.getContext("experimental-webgl",
>>>>>    { antialias: "false",
>>>>>      stencil: "false" });
>>>> I believe that is not allowed by the current spec, and will result in
>>>> a TypeError. It seems the intention of WebGL is that the second
>>>> argument is a WebGLContextAttributes object (though the WebGL spec
>>>> currently lacks the IDL defining that), in which case
>>>> http://dev.w3.org/2006/webapi/WebIDL/#es-interface is relevant. The
>>>> "{...}" object is not a host object, and WebGLContextAttributes
>>>> doesn't satisfy the criteria for allowing native object
>>>> implementations, so this won't work.
>>>> You'd have to say
>>>>  var attr = new WebGLContextAttributes();
>>>>  attr.antialias = "false";
>>>>  etc
>>>> Then (with the current definitions) you could already say
>>>>  attr.antialias = false;
>>>> because the NameSetter takes a DOMString argument, so the value on the
>>>> JS side will be automatically converted to a string (in this case
>>>> "false").
>>> The WebGL working group's intent with this interface was to allow a
>>> JavaScript object literal to be passed in for this argument. (Someone
>>> please correct me if I'm misspeaking.)
>> That is not what I recall, there were lots of discussions about it but I think we said it has to be a special object.
> I believe we did say we would allow a JS object literal to be used. That's why WebGLContextAttributes doesn't have a constructor.

This is my recollection as well, and it's also the reason the
NameGetter and NameSetter extended attributes were used. However we
didn't realize that this would prevent object literals from being
passed for this argument.

> Speaking of which, someone mentioned that we should be using the "editor's draft" of the WebIDL spec. But I can't find such a thing. Seems like WebIDL should be able to describe generic containers (Objects), since it can (at last viewing) supports sequences (Arrays).

It's what Philip pointed to above:



You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: