[whatwg] canvas, img, file api and blobs

[Joel Webber]

On Tue, Feb 16, 2010 at 2:25 PM, Stefan Haustein <haustein at google.com>wrote:

> On Tue, Feb 16, 2010 at 6:22 PM, Chris Marrin <cmarrin at apple.com> 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 a webgl buffer from an XHR response (which would be a *huge*
> improvement), we'd still need to parse the binary data when decoding JPEG
> headers, protocol buffers etc.
>
> Constructing ints / longs from bytes in Javascript will probably be slow,
> so in addition to the typed arrays, we'd love to have some kind of access
> that would be similar to Java's DataInput (+DataOutput, see
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInput.html ), but with
> endianess support....
>

Agreed with Stefan's point, although technically you could implement
getByte(), getShort(), et al with a bunch of TypedArray views onto a single
ArrayBuffer. But this is really, really ugly, because in the general case
you'd need 4 ByteArrays, 2 ShortArrays, etc. to deal with arbitrary offsets.
It would be much cleaner (and probably a bit more efficient) to implement
these getters directly in C++. This is pretty closely analogous to Java's
nio.ByteBuffer interface, though I think it would be better to hoist it out
into a separate interface.

As for quantitative data, I'm working on getting some together right now.
What I'd like to do (roughly) is to define a mesh format that looks very
roughly like this:

Mesh {
  int nVerts;
  float[] verts; // nVerts * 3
  int nFaces;
  int[] triIndices; // Maybe in strips
  // etc for materials and the like
}

And implement the fastest Javascript/JSON/whatever implementation for
getting one over XHR and loading it into WebGL.

I then plan on doing the equivalent with TypedArrays coming directly from
XHR into WebGL without Javascript having to touch every element. I've hacked
the WebGLArrays into TypedArrays, and implemented { ByteBuffer
XMLHttpRequest.resultBuffer } in my local WebKit, which I can then use to
compare performance. I strongly suspect that the latter will be enormously
faster, but could be proven wrong.

Note that to get reasonable performance in js, without TypedArray, you
pretty much *have* to switch to a text format like JSON. You can implement
(and we have) parsing of an arbitrary binary data structure in js, but it's
just freakishly slow and memory-inefficient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100216/20d56c72/attachment-0002.htm>