On Wed, Apr 16, 2014 at 10:45 AM, ben turner <[email protected]> wrote: > > > ---------- Forwarded message ---------- > From: Julien Wajsberg <[email protected]> > Date: Wed, Apr 16, 2014 at 9:30 AM > Subject: [b2g] Using blobs to display images > To: dev-b2g <[email protected]> > > > Hey, > > Basically, I'd like to know whether it's better to revoke a blob URL > just after an image has been loaded, even if it's still displayed, or to > keep the blob url valid until the image is hidden.
tl;dr: You should revoke it when the onload or onerror events fire. (I'm going to ignore some things like the Necko cache and image scaling for this discussion to avoid making it too complicated.) As far as the image layer of Gecko is concerned images loaded via the blob: protocol are no different than those loaded over http:, file:, data:, etc. Gecko does not in general assume that URL loading is idempotent. For certain protocols it is guaranteed to be (e.g. data) and for others it is not (e.g. http), but we generally assume it is not since a non-idempotent scheme (http) is by far the most dominant protocol on the web. This means that layers that require the original source data to be available must store it themselves. Not every part of Gecko has this requirement: the DOM can discard the source document after parsing because the DOM tree representation becomes the canonical copy of that data. But for images, where the uncompressed copy of the image can be several times the size of the copy we loaded off the network, we want to be able to discard the uncompressed copy to save memory. Thus imagelib must save the original compressed copies of the image itself. Thus, > Here is a rationale I can't remove from my mind: > * the image as a blob will likely be smaller (because it's compressed) > than the image as displayed (because it's uncompressed) That's correct, but this is also true of all non-bitmap images. The original source is essentially always smaller than the uncompressed copy that we need to paint to the screen. > * what should gecko do once the image is displayed? We will eventually > need the uncompressed data to repaint. Gecko attempts to be smart about when it decompresses images and how long it keeps that data around for before throwing it away and decompressing it again when it is needed next. The heuristics for this are certainly not perfect, and they may not be applied at all to certain things such as CSS background images. > * if the source is a http URL or a data URL, then gecko is confident > that the source will always be available; No, it's not. HTTP is not idempotent. What happens if you're offline, or your cookies that you need to view the image have expired? > therefore it could discard any > uncompressed data in case of memory pressure, because it could calculate > it again from the source. Gecko stores the compressed data for everything, so it can always discard uncompressed image data and recalculate it again when necessary. > * if the source is a blob URL and is revoked, then gecko won't be able > to get the uncompressed data once it's discarded, therefore we need to > keep it in memory. Right, but this is true of basically every protocol (except data:, but we don't have special behavior for them). > * if the source is a blob URL and still valid, we can argue both behaviors. > > I don't know _at all_ how much of what I describe here is true/wrong, > and therefore I hope somebody will be able to answer this, not in terms > of "what I think happens" but in terms of "what gecko is doing". The correct way to think of it is that revoking a blob URL only affects the network level. If loading/etc is complete it will generally have no effect. There are certain caveats to this for things that happen lazily (such as CSS background image loading, which only happens when there is an element that actually has the image as a background). - Kyle _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
