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

Re: [Public WebGL] WebGLContextAttributes

On Jan 6, 2010, at 5:41 PM, Kenneth Russell wrote:

> On Wed, Jan 6, 2010 at 5:28 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> On Jan 6, 2010, at 4:30 PM, Kenneth Russell wrote:
>>> On Wed, Jan 6, 2010 at 5:19 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>> On Jan 5, 2010, at 4:17 PM, Kenneth Russell wrote:
>>>> ,,,As Philip pointed out we also need to remove the NameSetter,
>>>> NameGetter and NameDeleter extended attributes. In other words, rather
>>>> than trying to specify it as a dictionary, we need to state which
>>>> attributes the DOM code will look up via callbacks. This is the IDL
>>>> which will give us the desired result:
>>>>    [Callback] interface WebGLContextAttributes {
>>>>        attribute boolean alpha;
>>>>        attribute boolean depth;
>>>>        attribute boolean stencil;
>>>>        attribute boolean antialias;
>>>>        attribute boolean premultipliedAlpha;
>>>>    };
>>>> Are there any objections to my updating the specification for
>>>> WebGLContextAttributes?
>>>> None from me. In fact, I would appreciate it!
>>>> Sections 5.1 and 5.1.1 have been updated. Feedback welcome.
>>>> Looking at the changes, it strikes me  that this is not as flexible as the
>>>> original design. Originally I had envisioned allowing any data type to be
>>>> passed in the attributes. This would allow in the future to, for instance,
>>>> pass the desired number of bits for the depth buffer, or a string describing
>>>> the antialias mode. I wonder if it would be reasonable to change the
>>>> attribute types to 'any' and state that in this release any value passed is
>>>> interpreted as a boolean, using normal ECMAScript conversion rules.
>>> I've updated the IDL and surrounding docs to take this suggestion into
>>> account. I have some doubts as to whether this scheme will be
>>> future-proof, though. If we change the semantics of the "depth"
>>> attribute in the future to indicate the minimum number of depth bits,
>>> then anyone who had explicitly put "true" for that attribute's value
>>> in their code might start getting a depth buffer of minimum 1 bit. It
>>> might be better to be explicit about the types and assume that we will
>>> add new attributes to cover things like number of alpha or depth bits.
>> This is why I have minimums for things like depth (16 bits). We should go over all the values, but hopefully we can make the definitions tight enough so that a boolean value today will maintain the same meaning in the future.
> I don't follow. The ECMAScript conversion rules dictate how values
> will be converted. If the depth attribute's natural type changes to
> long in the future, then presumably the default value will also change
> to 16. Code written today stating { depth: false } will be interpreted
> as zero bits of depth buffer, which is OK because it's still what the
> developer intended. However, if the developer wrote { depth: true },
> which is redundant but legal, then this will be interpreted as one bit
> of depth buffer since true converts to 1 via ToNumber() / ToInt32().

But if the IDL states that the type is passed as 'any', it is up to the spec to say what happens when different types are passed. So a future spec can say, "if the value passed is boolean, then true means a depth buffer of at least 16 bits is used, if false then no depth buffer is used. If the value passed is a number then a value of 0 means no depth buffer, otherwise it is the number of bits to use for the depth buffer with <some rules about how to map the value to acceptable depth values>". Then it's up to the JS binding, which knows the type being sent in, to do the right thing.

The only way your issue would arise is if we changed the type from 'boolean' to 'int' in the future. Then 'true' would get converted to '1' and we wouldn't know that was the author's intent. But 'any' doesn't have that problem.


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: