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

Re: [Public WebGL] WebGLContextAttributes



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().

-Ken

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