Open Bug 1125462 Opened 5 years ago Updated 3 years ago

When an image stops being locked, try to stop any running decoders and clean them up


(Core :: ImageLib, defect)

Not set




(Reporter: seth, Assigned: seth)



(Keywords: feature)


(1 file)

When an image stops being visible (becomes unlocked), we had the heuristic in the past that we'd stop any running decoders. It's not clear that in the long term we want to maintain this heuristic; in bug 1123976 we'll try to add code to be smarter about this. But in the short term, bug 1079627 caused a 70MB regression in memory usage after all tabs are closed in AWSY (that's bug 1122704) and we want to fix that.

In this bug, we'll add code that tries aggressively to stop running decoders and clean up after them (in particular, destroying the surfaces they create) as soon as we can.
Whiteboard: [MemShrink]
Depends on: 1125491
Here's the patch. I'm not going to request review just yet, though; I want to
see how bug 1125490 turns out first. I'm honestly still not a fan of this
behavior, and if bug 1125490 fixes the AWSY regression I intend to rewrite
this patch to be less aggressive.
Seth, how big are these decoders? How much memory is this likely to save? Even a rough guess would help. Thanks.
Flags: needinfo?(seth)
Decoders aren't that big. From a memory, as opposed to performance, perspective, the interesting thing is discarding the surfaces that the decoders are working on. I don't think the patch in this bug is the best way to achieve that; this approach is inherently racy. Bug 1125490 is the better fix.

At this point this bug is really more about performance, and the patch needs to be totally rewritten with that in mind.
No longer blocks: 1122704
Flags: needinfo?(seth)
Actually, an exception to "decoders aren't that big" is progressive JPEG decoding. See bug 1047096. The patch in this bug isn't the right way to deal with that, either.
Whiteboard: [MemShrink]
You need to log in before you can comment on or make changes to this bug.