Le 24/04/2014 08:34, Jonas Sicking a écrit : > On Sat, Apr 19, 2014 at 6:49 AM, Julien Wajsberg <jwajsb...@mozilla.com> > wrote: >>> At the very least you can revoke the URL when we stop displaying the >>> image. I.e. if we change the background to some other URL, or if that >>> part of the UI is completely hidden >> 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? > It uses valuable memory indeed. However releasing it once the image > stops being displayed is better than not releasing it at all. > > But note that if you get the Blob from indexedDB or from DataStore, > then the Blob and bloburl uses very little memory since it's basically > just a pointer into the database.
Okay, good to know, thanks. > >>> (I don't know what piece of UI >>> that we're talking about here). >> We're doing this in 2 parts of the UI: >> >> * displaying contacts pictures. This currently comes from the mozContacts >> API only. But for Facebook contacts this will eventually come from a >> Datastore or a local IDB as well. We might even do a local IDB for all >> contact's source too, in the future. > So there's a risk here that we'll display a large number of images at once > here. > > As long as all those blobs point to data in an IDB database that should be ok. Currently they don't, but they should once we use background-size. > >> * displaying attachments. Until very recently, we were generating thumbnails >> using the canvas API, and export them as data url, and use this as >> background-image. In bug 996516 we'll take advantage of the downsamping url >> feature to use directly the blob url in this. The data comes from the >> mozMobileMessage API, and from activities. > We really should not use data urls for anything. They suck up a lot of > memory. Not only does it keep the whole encoded image in memory. It > likely keeps several copies of it. And each copy is in a very > ineffective format (130-260% of binary size) We actually tried to get rid of it earlier (bug 889902 [1]) but using blobs proved to be worse than with dataurl (see comment 21). Probably we didn't try correctly, but anyway the new try using the samplesize and background-size should be way better. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=889902 > >>> Another solution here would be if we added support for URLs that map >>> directly into indexedDB. See >>> >>> http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0081.html >> Would that cross process boundaries? I guess not, and so would not be that >> useful for us. > Not sure what you mean by "process boundaries". IndexedDB is always > accessed through the parent process. As is any time that we load > something from the network. > > So in that sense this would indeed work across process boundaries. > > But if you mean being able to load another application's IDB data that > would not work. But that has nothing to do with process boundaries but > rather is by design. oki, that's what I wanted to mean, thanks :) -- Julien
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
