Greetings,
Images are common on the web, and image decoding is currently causing us a
lot of memory and performance problems -- we tend to do much worse than
other browsers on image-heavy pages. The details are spread across a range
of bugs, I wrote a summary to get the situation clear in my own head and
once I finished it I thought it was worth sharing. I've probably got some
details wrong, please correct me if I have.
Nick
TL;DR
If we fixed bugs 542158 and bug 661304 (both of which depend on bug 689623)
Firefox would suck much less on image-heavy pages. Fixing some other bugs
would help too.
BAD BEHAVIOUR #1
If you open a new page in the current tab, all images are decoded
immediately, in parallel.
This is a Snappy problem because visible images aren't given any priority,
which can cause flicker/delay.
https://bugzilla.mozilla.org/show_bug.cgi?id=715308#c37 is about this, it's
an unprioritized Snappy bug, and is assigned to jlebar.
(The patch in that bug also attempts to prevent decoding of lower priority
images from interfering with other browser operations, but it isn't working
as expected.
https://bugzilla.mozilla.org/show_bug.cgi?id=716103 has
details).
(Also, our JPEG decoding appears to be very slow:
https://bugzilla.mozilla.org/show_bug.cgi?id=715919.)
This behaviour is also a MemShrink problem because on pages with many
images (including various kinds of image slideshow) it causes excessive
memory consumption. To fix that we should not decode all the images
immediately, just the ones that are "visible or almost visible" (more about
that below).
https://bugzilla.mozilla.org/show_bug.cgi?id=542158 is open
for this, it's an unprioritized, unassigned MemShrink and Snappy bug.
(Actually, if bug 542158 is fixed, that'd reduce the importance of bug
715308 because we'd be decoding many fewer images at a time.)
BAD BEHAVIOUR #2
None of the decoded images in the foreground tab are ever discarded.
This behaviour also a MemShrink problem, for the same reason. We should
allow decoded images to be discarded if they are no longer "visible or
almost visible".
https://bugzilla.mozilla.org/show_bug.cgi?id=661304 is
open for this, it's a MemShrink:P1 and is assigned to jrmuizel.
"VISIBLE OR ALMOST VISIBLE"
Both these fixes depends on layout helping imagelib with the "visible or
almost visible" heuristic.
https://bugzilla.mozilla.org/show_bug.cgi?id=689623 is about this, it's a
MemShrink:P1 and is assigned to tnikkel. The heuristic may also have a
timing component (e.g. how long has it been since this image was "visible or
almost visible"). This heuristic will need careful tuning.
https://bugzilla.mozilla.org/show_bug.cgi?id=661304 has lots of discussion
about this heuristic.
(There's also
https://bugzilla.mozilla.org/show_bug.cgi?id=683290, which is
about discarding images in the foreground tab that are no longer in the DOM.
It's a MemShrink:P2 bug assigned to khuey and has patches, but is stalled on
Android problems. It sounds like bug 661304 subsumes this bug.)
(And there's
https://bugzilla.mozilla.org/show_bug.cgi?id=683286, which is
more fodder for the "visible or almost visible" heuristic.)
(And there's
https://bugzilla.mozilla.org/show_bug.cgi?id=691169, which
indicates that on Fennec, images in the foreground tab can be discarded?)
OTHER BEHAVIOURS
If you open a new page in a background tab, no images are decoded. This is
good. If you switch to that tab, all images are decoded immediately.
The decoded images in a tab you switch away from are discarded on a timer
(image.mem.min_discard_timeout_ms, which default to 10000, which means they
are discarded after 10 to 20 seconds). There has been some quibbling about
whether this is a good default... it depends greatly on how much RAM you
have, but compared to the above problems I think this is very minor.
TRACKING
We have
https://bugzilla.mozilla.org/show_bug.cgi?id=683284 open, which is a
meta-bug for tracking all the ways we handle images poorly. It tracks all
the bugs I've mentioned, plus some specific examples of pages where we do
badly compared to other browsers.