W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2010

[whatwg] canvas, img, file api and blobs

From: Stefan Haustein <haustein@google.com>
Date: Wed, 17 Feb 2010 13:07:30 +0000
Message-ID: <e41a53f1002170507u1a252f44g1dc44ff770b666fb@mail.gmail.com>
On Wed, Feb 17, 2010 at 1:04 PM, Stefan Haustein <haustein at google.com>wrote:

> 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
>

p.s. This would probably also address some of the reference vs. copy issues
raised in section 5 (
http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html#5 )


>
>
>
>
>
>> --
>> St?phane Epardaud
>>
>
>
>
> --
> Stefan Haustein
> Google UK Limited
>
> Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W
> 9TQ; Registered in England Number: 3977902
>
>


-- 
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/992321ac/attachment.htm>
Received on Wednesday, 17 February 2010 05:07:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:21 UTC