[Public WebGL] Typed Array setter for partial arrays (and typed array performance)

Gregg Tavares (wrk) [email protected]
Fri May 6 13:49:20 PDT 2011


On Thu, May 5, 2011 at 5:54 PM, Kenneth Russell <[email protected]> wrote:

>
> After looking at Brian's example below and giving this more thought
> I'm inclined to leave the new slice() method on ArrayBuffer. Doing so
> avoids the creation of two temporary Uint8Arrays, and I've received
> requests for this functionality from multiple individuals doing large
> file I/O, indicating it's worth providing it in the API rather than
> relying on third-party libraries to provide it.
>

I don't care either way but I'm missing the issue

// This is the original buffer. With or without slice you'll have this
var buffer = DataView.buffer;

// This is just a VIEW to the original buffer.
var tmpToCopy = new Uint8Array(buffer, start, end);  // Even though the data
is not all Uint8s

// This is a copy. This is actually the same copy that slice would make.
var tmpCopied = new Uint8Array(tmpToCopy);

// This is a reference to the new buffer.
var subBuffer = tmpToCopy.buffer;

// This is a VIEW on the buffer. We still only have 2 buffers.  The original
and the copied subsection.
var subView = new DataView(subBuffer);


There's no more or less copies than slice.  There's just a couple of small
temp VIEWs.



> -Ken
>
> On Mon, May 2, 2011 at 2:10 PM, Ben Vanik <[email protected]> wrote:
> > Yeah - this is the scenario I'm concerned about, and as you pointed out
> that
> > code is non-obvious and dirty. Just saying 'wrap it in function and drop
> it
> > on a prototype' is a cop-out for clean API design.
> >
> > --
> > Ben Vanik
> > http://www.noxa.org
> >
> >
> > On Mon, May 2, 2011 at 1:37 PM, Brian Cornell <[email protected]>
> wrote:
> >>
> >> So if you are using just an ArrayBuffer with a DataView and want to copy
> a
> >> subset of it (so the rest can be garbage collected, just keep a small
> part
> >> of it), is the recommendation to do the following?
> >> var buffer = DataView.buffer;
> >> var tmpToCopy = new Uint8Array(buffer, start, end);  // Even though the
> >> data is not all Uint8s
> >> var tmpCopied = new Uint8Array(tmpToCopy);
> >> var subBuffer = tmpToCopy.buffer;
> >> var subView = new DataView(subBuffer);
> >> That seems convoluted and unobvious, especially the fact that I have to
> >> treat my many-typed data as all Uint8s just because only TypedArrays
> have
> >> ways to copy data.
> >> -Brian
> >>
> >> On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell <[email protected]>
> wrote:
> >>>
> >>> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin <[email protected]>
> wrote:
> >>> >
> >>> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote:
> >>> >
> >>> >>
> >>> >> ...
> >>> >> As part of the planned Typed Array API changes to support efficient
> >>> >> communication with web workers, the plan is to add convenience
> methods
> >>> >> to copy ArrayBuffers and possibly sub-portions of them. I think we
> >>> >> should invest our time in moving those changes forward.
> >>> >
> >>> > Why is it necessary to have functions to copy ArrayBuffers. Isn't the
> >>> > copy constructor in the TypedArrays sufficient?
> >>>
> >>> That's a fair point. During one of the face-to-face meetings with
> >>> Mozilla it seemed that if we used transfer-of-ownership for
> >>> ArrayBuffers sent via postMessage, then we had to make it easy to copy
> >>> them. You're right, though, that the slice() operation can be easily
> >>> implemented in pure JavaScript, with the only cost the creation of two
> >>> temporary Uint8Arrays.
> >>>
> >>> Should we just get rid of it and provide non-normative text showing
> >>> how it could be implemented?
> >>>
> >>> -Ken
> >>> -----------------------------------------------------------
> >>> You are currently subscribed to [email protected]
> >>> To unsubscribe, send an email to [email protected] with
> >>> the following command in the body of your email:
> >>> unsubscribe public_webgl
> >>> -----------------------------------------------------------
> >>>
> >>
> >
> >
>
> -----------------------------------------------------------
> You are currently subscribed to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
> unsubscribe public_webgl
> -----------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110506/ed316868/attachment.html>


More information about the public_webgl mailing list