- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 27 Mar 2012 20:44:53 -0500
On Tue, Mar 27, 2012 at 7:12 PM, Kenneth Russell <kbr at google.com> wrote: > - I think it should reference DataView directly rather than > ArrayBufferView. The typed array spec was specifically designed with > two use cases in mind: in-memory assembly of data to be sent to the > graphics card or audio device, where the byte order must be that of > the host architecture; This is wrong, broken, won't be implemented this way by any production browser, isn't how it's used in practice, and needs to be fixed in the spec. It violates the most basic web API requirement: interoperability. Please see earlier in the thread; the views affected by endianness need to be specced as little endian. That's what everyone is going to implement, and what everyone's pages are going to depend on, so it's what the spec needs to say. Separate types should be added for big-endian (eg. Int16BEArray). I also disagree that it should use DataView. Views are used to access arrays (including strings) within larger data structures. DataView is used to access packed data structures, where constructing a view for each variable in the struct is unwieldy. It might be useful to have a helper in DataView, but the core API should work on views. - It would be preferable if the encoding API had a way to avoid > memory allocation, for example to encode into a passed-in DataView. > This was an earlier design, and discussion led to it being removed as a premature optimization, to simplify the API. I'd recommend reading the rest of the thread. -- Glenn Maynard
Received on Tuesday, 27 March 2012 18:44:53 UTC