Lots of big animated images use lots of memory

NEW
Assigned to

Status

()

Core
ImageLib
P3
normal
a year ago
3 months ago

People

(Reporter: jrmuizel, Assigned: tnikkel)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---
Bug Flags:
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

(Reporter)

Description

a year ago
There are lots of different options for how to deal with this. We should take one of them.
(Reporter)

Updated

a year ago
Blocks: 1296938
Whiteboard: [gfx-noted]
(Reporter)

Comment 1

a year ago
Timothy, Milan said you have the beginnings of a plan. Can you put it in this bug?
Assignee: nobody → tnikkel
Flags: needinfo?(tnikkel)
(Assignee)

Comment 2

a year ago
The idea was to allow discarding/redecoding of animatad images just like non-animated images. Dumping all the frames of an animated image on discard and redecoding them all on redecode. I _think_ we have all the pieces we need for this. Hopefully this isn't too hard, but I don't know all the places in the code that might be depending on never discarding animated images.
Flags: needinfo?(tnikkel)
We saw in Trello that this is targeting Firefox 55.

Does this need manual testing? If yes, could you provide some suggestions?
Flags: qe-verify?
Flags: needinfo?(tnikkel)
(Assignee)

Comment 4

7 months ago
Manual testing to make sure that animated images (gifs and pngs) work correctly after we've thrown out their image data and then decided to re-decode them could be good.

First we need a way to trigger discarding of the image data. This requires two steps:
1) making the image not-visible
2) trigger memory pressure

For 1) the two mains things to test are putting the image in a background tab (a tab that is not visible or active) and scrolling the image well out of view (we still keep around images that are close to being visible via scrolling, so make sure to scroll a very far way away from the image.

For 2) the easiest way is to open about:memory in a new window and clicking minimize memory usage.

There are at least three different types of animated images to check:
1) infinite looping
2) finite length (ie they stop animating at some point) that have stopped animating
3) finite length that are still animating

For infinite looping images we want to check that they:
1) redecode and display
2) continue animating
3) it doesn't seem to "fast forward", but instead animates at the correct rate
4) there are no glitches

For finite length images that have stopped animating we want to check that they:
1) redecode and display
2) only displays the correct final frame
3) does not animate
4) there are no glitches

For finite length images that are still animating we want to check that they:
1) redecode and display
2) continue animating
3) it doesn't seem to "fast forward", but instead animates at the correct rate
4) there are no glitches
5) it stops when it gets to the end

The implementation is in bug 1343341. And I plan to turn on the pref in bug 686905. (Note that it hasn't all landed yet.)
Flags: needinfo?(tnikkel)
Thanks Timothy, we'll see whether we'll track this as a feature (with formal sign offs and a test plan) or as bug verification work. Regardless, I think we'll want to also do a sanity check on normal image support to make sure nothing breaks there after we have this implemented.

Timothy, if at any point you think your implementation may break some other stuff please do let us know so we can test other areas at risk.
Flags: qe-verify? → qe-verify+
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.