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

Re: [Public WebGL] Problem with typed arrays in firefox



On Wed, Oct 13, 2010 at 4:10 PM, alan@mechnicality.com
<alan@mechnicality.com> wrote:
>  Hi Ken - looking at some of the later messages in the thread it seems that
> this was a known bug but I'll file a report if you still want me to.

No, Adrienne pointed out it's already filed.

> Vlad, sorry to cast aspersions on Firefox! I'll fix my code to pad to a word
> boundary.
>
> However, one reason that this came up that I was is in trying to access
> int32 data in an heterogeneous array. If we stick to the spec as it stands
> then it means that it becomes a requirement that the array buffer is padded
> to either modulo 2, 4,  or 8 if *any* of the data in the buffer is 2, 4, or
> 8 bytes in size and you access that data using an ArrayBufferView.

This is not the case. It's only true if you're using the constructor
that takes a byte offset but no length. It's a requirement that typed
array views start at a byte offset that is a multiple of their element
size (i.e., aligned accesses only) so you may need to pad at the
beginning of a region of a particular type, but not necessarily at the
end.

-Ken

> I think
> we should consider the implications of this. So, if you have (say) a mixture
> of floats and bytes in a vertex array the length of the buffer could change
> to not be a multiple of 4 without the programmer necessarily being aware of
> it.
>
> Its probably worth pointing this out somewhere.
>
> Thanks
>
> Alan
>
>
>
>
> On 10/13/2010 2:29 PM, Kenneth Russell wrote:
>>
>> It's definitely a bug in Chrome / WebKit. Alan, could you please
>> create an account on bugs.webkit.org and file it? Component WebGL, and
>> CC: my email address. Or let me know if you would prefer I do it.
>>
>> -Ken
>>
>> On Wed, Oct 13, 2010 at 2:18 PM, Vladimir Vukicevic
>> <vladimir@mozilla.com>  wrote:
>>>
>>> That seems correct to me, and Chrome might have the bug -- a
>>> 29/30/31-byte ArrayBuffer can't be evenly divided into 4-byte Unit32
>>> segments.  The spec states:
>>>
>>>> The given byteOffset must be a multiple of the element size of
>>>> the specific type, otherwise an exception is raised.
>>>>
>>>> If a given byteOffset and length references an area beyond the
>>>> end of the ArrayBuffer an exception is raised.
>>>>
>>>> If length is not explicitly specified, the length of the ArrayBuffer
>>>> minus the byteOffset must be a multiple of the element size of the
>>>> specific type, or an exception is raised.
>>>
>>> byteOffset is 0 if it isn't specified, so the third clause here applies
>>> in both cases.  The 0,4 case succeeds, because an explicit offset and length
>>> is given -- the resulting Uint32Array will have length 4, where 4*4=16 is
>>> less than 29/30/31 so that will succeed.
>>>
>>>    - Vlad
>>>
>>> ----- Original Message -----
>>>>
>>>> I think this may be a bug - if so I'll file a bug report.
>>>>
>>>> With firefox 4.b6 on win 7 x64 I'm seeing the following behavior:
>>>>
>>>> function testCase(size) {
>>>> ab = new ArrayBuffer(size);
>>>> try {
>>>> var xyz = new Uint32Array(ab);
>>>> } catch(err) {
>>>> debug("!" + err + " no args");
>>>> }
>>>> try {
>>>> var xyz = new Uint32Array(ab, 0);
>>>> } catch(err) {
>>>> debug("!" + err + " start");
>>>> }
>>>> try {
>>>> var xyz = new Uint32Array(ab,0,4);
>>>> } catch(err) {
>>>> debug("!" + err + " start, offset");
>>>> }
>>>>
>>>> }
>>>>
>>>> gives if size is not a multiple of 4. For example:
>>>> !Error: invalid arguments no args
>>>> !Error: invalid arguments start
>>>>
>>>> testCase(28); // OK
>>>> testCase(29); // FAILS
>>>> testCase(30); //FAILS
>>>> testCase(31); // FAILS
>>>> testCase(32); //OK
>>>>
>>>> This applies to ff b6 win 7 x64. Chrome works fine. I've tried the
>>>> latest build but it crashes as
>>>> soon as I open it.
>>>>
>>>> Thanks
>>>>
>>>> Alan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----------------------------------------------------------
>>>> 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:
>>>
>>>
>
>
> --
> Alan Chaney
> CTO and Founder, Mechnicality, Inc.
> www.mechnicality.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: