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 <[email protected]> wrote: > On Tue, Sep 28, 2010 at 9:39 AM, Boris Zbarsky <[email protected]> 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 >> >> >
