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

Re: [Public WebGL] TypedArray spec updates



On Wed, May 12, 2010 at 11:50 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On May 11, 2010, at 5:31 PM, Kenneth Russell wrote:
>
>> Several long-overdue updates to the TypedArray spec have been checked in:
>> - Added Web IDL.
>> - Added links to spec and IDL.
>> - Added editors.
>> - Added ArrayBufferView supertype.
>> - Specified that newly created ArrayBuffers are initialized to 0.
>> Thanks to Joshua Bell for pointing out the omission.
>> - Defined INDEX_SIZE_ERR is raised for situations related to
>> out-of-range indices.
>> - Removed specification of exception behavior for unsigned values < 0.
>> - Removed specification of exception behavior for the case where
>> sequence<type> is passed to the constructor; Web IDL specifies
>> overloading behavior.
>> - Specified TypedArray.set(); wording adapted from WebGL spec.
>> - Fixed slice() to take long arguments instead of unsigned long.
>> - Removed redundant "in" qualifiers from arguments.
>> - Added types to method and property specifications in detail boxes.
>> - Reorganized methods in DataArray view to match ordering elsewhere.
>> - Tightened up slice() specification. Thanks to Joshua Bell.
>
> Great. This spec is really shaping up.
>
> I still don't understand the DataArray API. I don't see why we need a separate view that is essentially an uberview, being able to view any offset as any type. That seems like overkill. It seems like it would be better if each view had a setter and getter that took an ArrayBuffer and a littleEndian flag. The flag would tell you the byte order of the data in the ArrayBuffer. Let's say I have some future version of XHR, which can give me data as an ArrayBuffer. Then I could do this:
>
>        function XHRDataReady(request)
>        {
>                var data = request.responseArrayBuffer; // New imaginary XHR API
>                var buffer = new ArrayBuffer(10 * 2 + 10 * 4); // enough space for 10 shorts and 10 floats
>                var shorts = new Int16Array(buffer, 0, 10);
>                var floats = new FloatArray(buffer, 10 * 2, 10);
>                shorts.setData(data, 0, 10, true); // Data I loaded with XHR is littleEndian
>                floats.setData(data, 10 * 2, 10, true);
>        }
>
> This would flip the order of the incoming data or not, as needed.
>
> With your API, would I use it like this:
>
>        function XHRDataReady(request)
>        {
>                var data = request.responseArrayBuffer; // New imaginary XHR API
>                var dataArray = new DataArray(data);
>
>                var buffer = new ArrayBuffer(10 * 2 + 10 * 4); // enough space for 10 shorts and 10 floats
>                var shorts = new Int16Array(buffer, 0, 10);
>                var floats = new FloatArray(buffer, 10 * 2, 10);
>
>                // Set the shorts
>                for (var i = 0; i < 10; ++i)
>                        shorts[i] = dataArray.getInt16(i * 2, true);
>
>                // Set the floats
>                for (var i = 0; i < 10; ++i)
>                        floats[i] = dataArray.getFloat(i * 4 + 10 * 2, true);
>        }
>
> First of all, I'm not sure passing 'true' is the right thing to do. I know my data is littleEndian, but don't I have to check to see if the data in the arrays needs to be littleEndian and then flip the flag if needed?
>
> Second of all, it seems like having the uber-view is more complicated than just putting the API on the existing views.

The design constraints are:

 - Support unaligned loads / stores. This is a requirement to handle
arbitrary file formats.
 - Support specified endianness rather than "native" endianness as in
the TypedArrays. Most file formats are defined in terms of big-endian
or little-endian values.
 - Do not slow down the fast path of the typed arrays.

The best way to achieve all of these goals is to provide an
alternative view, decoupled from the typed arrays. Doing so avoids any
conditionals in the fast path of the typed arrays, while still
providing reasonably fast access via the new view's getters and
setters, which can be implemented with a few machine instructions
each.

Your proposal above doesn't handle the unaligned data case.

> Perhaps an example of the best way to use DataArray would help?

I envision most users wrapping it into a stream-like interface,
fetching individual data elements of various types and incrementing
the byte offset of the stream. The proposal I originally sent out was
of that form, though I agree based on your earlier feedback that
lower-level functionality should be provided and this implemented in
JavaScript.

-Ken

> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
>

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