Kenneth Russell kbr at google.com
Tue Apr 2 15:23:37 PDT 2013

On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte <vitteaymeric at gmail.com> wrote:
> Le 02/04/2013 04:24, Kenneth Russell a écrit :
>> Agreed. DataView's methods are all simple and should be easy to
>> optimize. Because they include a conditional byte swap, they can't run
>> quite as fast as the typed arrays' accessors -- but they shouldn't
>> need to. DataView was designed to support file and network I/O, where
>> throughput is limited by the disk or network connection. The typed
>> array views were designed for in-memory assembly of data to be
>> submitted to the graphics card, sound card, etc., and must run as fast
>> as possible.
> When you are streaming things, what's the correct use of DataViews?
> ie : you are supposed to create each time you want to read some bytes a
> DataView (which can be optimized or whatever, but still with some costs)?
> Maybe it's outside of the scope of this discussion, I have already provided
> examples, I still suspect that I am using it wrongly or that ArrayBuffers
> are more adapted to webgl (ie static buffer manipulation) than network
> streaming (ie dynamic buffer manipulation).
> Probably I am wrong but really would like to know then what's the correct
> use.

If I understand your question, then the correct use of DataView is:
upon receiving an ArrayBuffer, create a DataView referring to it. When
iterating down the contents of the ArrayBuffer, continue to use the
same DataView instance, just incrementing the offset. In
abstract-tls/lib/abstract-tls.js there are some operations which
create a new DataView just to read or write a single element; this
isn't the correct usage.
http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ may be a
useful reference.

If you're handling streaming data then presumably you're receiving
multiple ArrayBuffers, one after the other. You should create one
DataView per buffer. The only challenge is properly handling the
boundary from one buffer to the next, if the boundary is within an
element like a uint16 or uint32.


More information about the es-discuss mailing list