Julien Wajsberg <[email protected]> writes: > Le 19/04/2014 16:39, Andrew Sutherland a écrit : >> On 04/19/2014 09:49 AM, Julien Wajsberg wrote: >>> Yes that's also a possibility I had in mind. Aren't we taking up >>> valuable memory if you keep the blob url valid? Or is that memory >>> used anyway, because the image is displayed, and as a result it >>> would not take more than what's already taken? >> >> If it's a memory-backed Blob and that's the only reference to it, I >> believe the answer is yes because you are keeping both the Blob JS >> Object/its backing XPCOM object and its referenced data alive. > > David and Jonas and Kyle were saying that imglib keeps the compressed > data in memory to display it. So my question was more: does it do a > real copy of it, or does it do a fake copy that is just another > reference? What about imglib just keeping a ref to the blob instead of > copying the data? (That's what Thinker is suggesting in [1]).
imagelib does keep a real copy of the compressed data in memory and use that to decode when needed. > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=996512#c4 >> If it's backed by a file on disk such as a File/Blob reference >> provided by IndexedDB, you're only keeping the smallish JS >> Object/XPCOM object alive so it's less bad. >> >> In general if you have a memory-backed Blob you really want to: >> - Save it to IndexedDB or DeviceStorage immediately if you are going >> to ever save it to those spots. >> - Get a *new* reference to the Blob and forget all your old >> references to the memory backed Blob. > > > I would think that Gecko could do this for me if it needs the > memory. Like a swap mechanism. Seth and I had discussed about saving memory-backed Blob & other temporary resources to necko cache for just one session. I'm not sure if we could pin a resource in necko already. Note that even file-backed Blob will be copied by imagelib. So the blob:// I mentioned in bug 996512 is actually referring to file-backed Blobs. Kanru _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
