<div class="gmail_quote">On Tue, Feb 16, 2010 at 2:25 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 Tue, Feb 16, 2010 at 6:22 PM, Chris Marrin <span dir="ltr"><<a href="mailto:cmarrin@apple.com" target="_blank">cmarrin@apple.com</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><div>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.</div>
</div>

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

</blockquote><div><br></div></div></div><div>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. </div>

<div><br></div><div>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 <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInput.html" target="_blank">http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInput.html</a> ), but with endianess support....</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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:</div><div><br></div><div>Mesh {</div>
<div>  int nVerts;</div><div>  float[] verts; // nVerts * 3</div><div>  int nFaces;</div><div>  int[] triIndices; // Maybe in strips</div><div>  // etc for materials and the like</div><div>}</div><div><br></div><div>And implement the fastest Javascript/JSON/whatever implementation for getting one over XHR and loading it into WebGL.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div>