[whatwg] canvas, img, file api and blobs

[Stefan Haustein]

On Wed, Feb 17, 2010 at 8:35 AM, Stef Epardaud <stef at epardaud.fr> wrote:

> On Tue, Feb 16, 2010 at 07:25:34PM +0000, Stefan Haustein wrote:
> >      We've been getting pretty good traction on Vlad's ArrayBuffers
> proposal,
> >      which was taken from the WebGL spec. Our current plan is to change
> the
> >      names in the browsers (WebKit, Chrome and Mozilla) to the "non-WebGL
> >      specific" names Vlad proposes in his spec. We'd really like this to
> be the
> >      "one true binary data access" mechanism for HTML. We're talking to
> the
> >      File API guys about this and I think this API can be adapted in all
> the
> >      other places as well.
> >      As far as performance goes, can you point me at some quantitative
> data?
> >      When you say it's an "orders-of-magnitude" bottleneck, what are you
> >      comparing it to? The API is very new and we certainly want to
> improve it
> >      for the various purposes it can be put to. We've even talked about
> >      optimizations inside the JS implementations to improve access
> performance.
>
> If we can get something akin to Java's System.arraycopy (
>
> 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
> ) then the ArrayBuffer proposal would work for me :)
>
> If we cannot copy ArrayBuffer ranges by blocks in an effecient manner,
> then it's going to be very limiting.
>

The array based set method would let you do this:

function arrayCopy(src, spos, dst, dpos, len) {
  dst.set(src.slice(spos, len), dpos);
}

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.

Stefan





> --
> Stéphane Epardaud
>



-- 
Stefan Haustein
Google UK Limited

Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
9TQ; Registered in England Number: 3977902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100217/b6015e69/attachment-0001.htm>