2008-01-27 linux trunk nightly The image.animation_mode preference has a "once" setting, that makes animated images go through their animation once and then stop. This works, but when the image goes offscreen (page down, change tabs, etc.) for 10 seconds or more and then comes back on screen, it reanimates. This is a recent regression, and I'm betting it has something to do with the recent optimizations to images' memory use or whatever it was.
Yeah, I'm betting that the image state isn't kept across having the decoded image being destroyed and redecoded for display. That said, if we have to redecode it, I'm not quite sure how we get back to the last frame without reanimating it. There is no way for a UI for image.animation_mode, right? I'd be tempted to just leave this as is. Stuart, what do you think here?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
Flags: blocking1.9+ → blocking1.9-
Wouldn't this also be a problem for images with a non-looping animation? So the UI thing doesn't matter that much....
For what it's worth, it makes sites that actually use a non-looping animation a huge pain to scroll around, because the animations happen over and over...
Priority: P4 → P1
I should also note that this could be an accessibility problem because for some users the repeated animations cause serious problems in use of the browser.
Even with image.animation_mode = default, we still reanimate after some time offscreen. I highly suspect that this is caused by animated images being discarded and then redecoded. This is backed up by the fact that GIF images aren't discarded, and this is not reproducible for GIF images. This has nothing to do with the recent imglib cache changes.
Assignee: nobody → joe
Component: Image: Painting → ImageLib
Flags: blocking1.9.1- → blocking1.9.1?
QA Contact: image.gfx → imagelib
Summary: images reanimate after 10 seconds of being offscreen with image.animation_mode = once → images reanimate after some time offscreen
The correct solution is to make animated images properly restorable; this would involve keeping track of where we've decoded to (i.e., what frame we're on) and being able to replay that in some sort of offscreen buffer. That's a fairly risky move this late in the game, and I expect that it has very little impact on the user experience, so I'd rather just disable discarding of animated images altogether.
Flags: blocking1.9.1? → blocking1.9.1+
Summary: images reanimate after some time offscreen → [PATCH] images reanimate after some time offscreen
Pushed to mozilla-central in http://hg.mozilla.org/mozilla-central/rev/7ad0f93730cc After some baking, I'll push this to 1.9.1.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
I backed out this and the changes for bug 468160 due to leaks on the tinderbox.
Repushed in http://hg.mozilla.org/mozilla-central/rev/e10eb9ed18ed Once again, after some baking, I'll push to 1.9.1.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago → 11 years ago
Resolution: --- → FIXED
Note, for APNG's the restoreData is still created, even if animated images are now never 'discarded'. So, one should either not create restoreData for those images, or discard the restoreData when they will be never discarded. Followup bug?
filed bug 500402 as a followup to make animated images properly discardable. Hopefully I'll get to it soon in my restructuring of the discard code for decode-on-draw.
You need to log in before you can comment on or make changes to this bug.