On Sat, Apr 19, 2014 at 6:49 AM, Julien Wajsberg <[email protected]> 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. >> (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. > * 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) >> However it would also be good to have some sort of event fired once >> layout code has fully loaded any resources that it depends on, such as >> background images. However I just talked to dbaron and he pointed out >> that this would be of pretty narrow functionality since it wouldn't >> necessarily mean that the page is ready to be painted (asynchronous >> image decoding might still need to happen), and it also wouldn't work >> in cases where we avoid doing image loads for images that are outside >> of the current visible part of the page. > > Does that mean that revoking after 30 seconds would not work either in some > situations? In current gecko it should be fine. But there is indeed some risk that it'd break in the future. But more to the point the "fire an event when layout is done" solution wasn't as easy as I had hoped. >> 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. Using the URLs above you would be able to access the exact same data that you can through the IDB API. It just saves you the work of getting a Blob from the IDB API and calling createObjectURL on that Blob. And because you don't call createObjectURL you also wouldn't have to worry about when to call revokeObjectURL. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
