<br><br><div class="gmail_quote">On Wed, Feb 17, 2010 at 1:04 PM, Stefan Haustein <span dir="ltr"><<a href="mailto:haustein@google.com">haustein@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Wed, Feb 17, 2010 at 8:35 AM, Stef Epardaud <span dir="ltr"><<a href="mailto:stef@epardaud.fr" target="_blank">stef@epardaud.fr</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Feb 16, 2010 at 07:25:34PM +0000, Stefan Haustein wrote:<br>
>      We've been getting pretty good traction on Vlad's ArrayBuffers proposal,<br>
>      which was taken from the WebGL spec. Our current plan is to change the<br>
>      names in the browsers (WebKit, Chrome and Mozilla) to the "non-WebGL<br>
>      specific" names Vlad proposes in his spec. We'd really like this to be the<br>
>      "one true binary data access" mechanism for HTML. We're talking to the<br>
>      File API guys about this and I think this API can be adapted in all the<br>
>      other places as well.<br>
>      As far as performance goes, can you point me at some quantitative data?<br>
>      When you say it's an "orders-of-magnitude" bottleneck, what are you<br>
>      comparing it to? The API is very new and we certainly want to improve it<br>
>      for the various purposes it can be put to. We've even talked about<br>
>      optimizations inside the JS implementations to improve access performance.<br>
<br>
</div>If we can get something akin to Java's System.arraycopy (<br>
<a href="http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#arraycopy%28java.lang.Object,%20int,%20java.lang.Object,%20int,%20int%29" target="_blank">http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#arraycopy%28java.lang.Object,%20int,%20java.lang.Object,%20int,%20int%29</a><br>


) then the ArrayBuffer proposal would work for me :)<br>
<br>
If we cannot copy ArrayBuffer ranges by blocks in an effecient manner,<br>
then it's going to be very limiting.<br></blockquote><div><br></div></div></div><div>The array based set method would let you do this:</div><div><br></div><div>function arrayCopy(src, spos, dst, dpos, len) {</div><div>
  dst.set(src.slice(spos, len), dpos);</div>
<div>}</div><div><br></div><div>If I understand Vladimir's response correctly, its omission from his ECAMScript proposal is unintentional (it is present in the WebGL spec) and will be fixed.</div><div><br></div><div>
Stefan</div></div></blockquote><div><br></div><div>p.s. This would probably also address some of the reference vs. copy issues raised in section 5 (<a href="http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html#5">http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html#5</a> )</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888">--<br>
Stéphane Epardaud<br>
</font></blockquote></div><div><div></div><div class="h5"><br><br clear="all"><br>-- <br>Stefan Haustein<br>Google UK Limited <br><br>Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ; Registered in England Number: 3977902<br>

<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Stefan Haustein<br>Google UK Limited <br><br>Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ; Registered in England Number: 3977902<br>
<br>