[PATCH] images reanimate after some time offscreen

RESOLVED FIXED

Status

()

Core
ImageLib
P1
normal
RESOLVED FIXED
10 years ago
7 months ago

People

(Reporter: dolphinling, Assigned: Joe Drew (not getting mail))

Tracking

({access, fixed1.9.1, regression})

Trunk
x86
Linux
access, fixed1.9.1, regression
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9.1 +
wanted1.9.1 +
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.
Flags: blocking1.9?
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....

Updated

9 years ago
Flags: wanted-next+
Blocks: 296818
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...
Flags: blocking1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
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.
Keywords: access
(Assignee)

Updated

9 years ago
Duplicate of this bug: 459618
(Assignee)

Comment 6

9 years ago
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
(Assignee)

Comment 7

9 years ago
Created attachment 350205 [details] [diff] [review]
Disable discarding of animated images

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.
Attachment #350205 - Flags: superreview?(vladimir)
Attachment #350205 - Flags: review?(pavlov)
Attachment #350205 - Flags: superreview?(vladimir)
Attachment #350205 - Flags: superreview+
Attachment #350205 - Flags: review?(pavlov)
Attachment #350205 - Flags: review+
Flags: blocking1.9.1? → blocking1.9.1+
Summary: images reanimate after some time offscreen → [PATCH] images reanimate after some time offscreen
(Assignee)

Comment 8

9 years ago
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: 9 years ago
Resolution: --- → FIXED

Comment 9

9 years ago
I backed out this and the changes for bug 468160 due to leaks on the tinderbox.

Updated

9 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 10

9 years ago
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: 9 years ago9 years ago
Resolution: --- → FIXED
(Assignee)

Comment 11

9 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/dc188ed0b198
Keywords: fixed1.9.1

Comment 12

9 years ago
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.
Blocks: 686905
You need to log in before you can comment on or make changes to this bug.