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

Re: [Public WebGL] Clarification to bufferData



On Thu, Nov 11, 2010 at 2:00 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
>
>
> On Thu, Nov 11, 2010 at 1:54 PM, Vladimir Vukicevic <vladimir@mozilla.com>
> wrote:
>>
>>
>> ----- Original Message -----
>> > I've committed a small clarification to the bufferData variants taking
>> > ArrayBuffer and ArrayBufferView indicating that they generate an
>> > INVALID_VALUE error if null is passed for the buffer or view. This
>> > behavior is strongly desired because it is ill defined what happens
>> > otherwise. (Does the call become a no-op? Is the buffer object resized
>> > to zero size?)
>>
>> FWIW, for us currently we try to convert the arg to a non-null ArrayBuffer
>> or ArrayBufferView, and if that fails then we do the JS standard "ToInt32()"
>> operation to get a size.  For null that'll give us back 0, so we end up
>> treating it as resizing the buffer to 0-size.  Not sure if that's any better
>> or worse; I have no problem with the change.
>
> That seems more consistent with WebIDL.  Since one variant of bufferData
> takes a GLsizei you can basically pass anything to it and it should do the
> standard JS / EMCAScript thing which means passing null or "foo" or
> undefined etc will all convert to 0.

I'm not sure this analysis is correct. In overloaded constructor
invocations in Web IDL, passing null would cause the ArrayBuffer and
ArrayBufferView variants to be selected over the GLsizei variant per
the following sections:

http://dev.w3.org/2006/webapi/WebIDL/Overview.html#idl-overloading
http://dev.w3.org/2006/webapi/WebIDL/Overview.html#es-interface-call

In particular because null maps to "the object types, all nullable
types and all array types" (Section 4.4.1.1 step 3.2.2).

I'm not 100% sure how this works in normal overloaded calls but I
think the behavior is defined in
http://dev.w3.org/2006/webapi/WebIDL/Overview.html#call , which
implies that the method selected is ambiguous given that we don't have
a preference defined in the WebGL IDL.

We'd be able to distinguish this properly in Java or other statically
typed languages, so I think it's worth defining the behavior as is in
the case that those methods can be selected when null is passed.

-Ken

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

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