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]).
[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.
--
Julien
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
