Based on these constraints, it sounds like we either have to live with the
fact that we'll keep both a binary copy and a text copy around as we're
receiving XHR bytes. Or, we need a way to specify up-front that we're
interested in loading as binary (before calling send()) and not handle
binary in the default case.
Chris
On Tue, Sep 28, 2010 at 12:05 PM, James Robinson <jamesr@google.com> wrote:
> On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 9/28/10 10:32 AM, Chris Marrin wrote:
>>
>>> I'd hate the idea of another flag in XHR. Why not just keep the raw bits
>>> and then convert when responseText is called? The only disadvantage of this
>>> is when the author makes multiple calls to responseText and I would not
>>> think that is a very common use case.
>>>
>>
>> It's actually reasonably common; Gecko had some performance bugs filed on
>> us until we started caching the responseText (before that we did exactly
>> what you just suggested).
>>
>> Oh, and some sites poll responseText from progress events for reasons I
>> can't fathom.
>>
>
> A number of sites check .responseText.length on every progress event in
> order to monitor how much data has been received. This came up as a
> performance hotspot when I was profiling WebKit's XHR implementation as
> well.
>
> - James
>
>
>
>>
>> -Boris
>>
>>
>