We've got these fancy typed arrays, which means we can now do something sane with binary data read via XHR.
Created attachment 451704 [details] [diff] [review] initial attempt I can't test or even compile this until bug 560643 lands (which adds jsval to xpconnect), but does this seem like the right approach? I roughly copied what the string variant does.
Comment on attachment 451704 [details] [diff] [review] initial attempt Seems all good to me!
Created attachment 455903 [details] [diff] [review] updated & fixed Updated and tested -- this marks the workers version as not implemented, only because I didn't understand the various proxy layers to see how it should actually be done. We can fix that up in a followup.
Cc'ing bent, who says he knows how to navigate the workers maze..
Can I get me an r+ for b3? :)
http://hg.mozilla.org/mozilla-central/rev/b0a91fbddbff
Now documented in the XMLHttpRequest reference: https://developer.mozilla.org/en/XMLHttpRequest#Properties With discussion on the Using XMLHttpRequest page: https://developer.mozilla.org/En/XMLHttpRequest/Using_XMLHttpRequest#Receiving_binary_data_using_JavaScript_typed_arrays And mentioned on the Firefox 4 for developers page.
Hi folks, Thanks for adding this feature. I have recently been using XHR to download image data and convert it to a base64 data: URI. I have been doing this via the charCodeAt hack, but decided to try out mozResponseArrayBuffer to see if it was faster (where supported). I was surprised to discover that it is actually significantly slower: http://jsperf.com/encoding-xhr-image-data (Note: In my actual code, after I have built the 'binary' string variable, I am using window.btoa to base64-encode it an construct the data: uri.) Is this to be expected? I'd be happy to file a separate bug if appropriate, please let me know. Thanks, Jon
Jon, you're mostly seeing an artifact of the jsperf benchmark framework: it assumes that the time it takes to do an operation N times is N times the amount of time it takes to do the operation one time. Unfortunately, that's not the case, especially for operations where some intermediate results is expensive to compute but can be cached. In this particular case, when you do .mozResponseArrayBuffer we create a new array buffer, memcpy our internal buffer into it, and then return it. Doing this N times is in fact N times as costly as doing it once. Perhaps we should cache the resulting array buffer, though... that might be worth a bug. When you do .responseText the _first_ time we have to go and create a Unicode string from the bytes. Then we hand it out to JS, which mostly involves incrementing the string's reference count. This part does NOT involve another copy. We cache the Unicode string, so getting .responseText a second time is much faster. Here doing it N times is not N times as costly as doing it once. So whether the jsperf numbers are meaningful depends on how your code is structured (as usual for benchmarks). As long as your code is structured to only get the response once and then process it, I would expect .mozResponseArrayBuffer to be faster than .responseText. If it does get the response over and over again, then as currently written it'll be slower (and create a lot more GC pressure), as indicated by the jsperf results.
Hi Boris, Thanks for your detailed explanation. You are correct that in my "real world" I am not iterating the bytes more than once. I realised another thing: that I had forgotten to set the Access-Control-Allow-Origin header on the image, so nothing was actually being downloaded by the XHR anyway. I have now set the header. I have created a modified test which does more of the work once in the prelude: http://jsperf.com/encoding-xhr-image-data/4, and mozResponseArrayBuffer does indeed come out slightly better here. Cheers, Jon
Jon, thanks for retesting! I filed bug 639598 to consider caching the array buffer in the getter, but there are some serious problems with doing it... we'll see.
*** Bug 337434 has been marked as a duplicate of this bug. ***
