Alon Zakai (:azakai) Reporter
	Description • 14 years ago

Carefully, though - need to remember where they are, and fast-forward them when the tab returns to the top. See helpful comment at https://bugzilla.mozilla.org/show_bug.cgi?id=359608#c29

	Cees T.
	Comment 1 • 14 years ago

Sounds like a duplicate of bug 120154 - animated GIF eating cpu when mozilla in another tab or minimized.

	Alon Zakai (:azakai) Reporter
	Comment 2 • 14 years ago

Given all the fallout from bug 359608, I think it is not realistic to tackle this any time soon.

	Alon Zakai (:azakai) Reporter
	Comment 3 • 14 years ago

Fennec shouldn't block on this.

	Tim Taubert [:ttaubert] (inactive)
	Comment 4 • 13 years ago

I was about to file this because it noticeably shortens battery life and probably also responsiveness. How are the chances of this getting fixed?

	Ryan VanderMeulen [:RyanVM]
	Comment 5 • 13 years ago

Aren't images in background tabs throttled down to 1fps now that they're on the refresh driver?

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 13 years ago

Refresh driver is throttled to exponential backoff, not 1fps.

For the rest, good question...

	Scott Johnson (:jwir3)
	Comment 7 • 13 years ago

I think this will probably be required as part of bug 686905, at least if we want to discard animated image frames from background tabs.

I'm not sure if this is the idea, but we might be able to save memory by discarding frames that aren't being used at the moment. This would require that we redecode, though, but we could save the state of the image & then immediately jump to it once we've done the redecode.

	Boris Zbarsky [:bzbarsky]
	Comment 8 • 13 years ago

I think this bug is just about not running the animation code and the timers for it for images in background tabs, not about the image data per se.

	Phoenix
	Comment 9 • 13 years ago

Small question: could animation also be stopped if window with it completely covered by other window?

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 13 years ago

That's actually very difficult to impossible to detect (e.g. just because you're covered doesn't mean you're invisible: windows can be translucent or transparent).

	Phoenix
	Comment 11 • 13 years ago

So, this two articles are not helpful because of transparency now?
http://blogs.msdn.com/b/oldnewthing/archive/2003/08/29/54728.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2003/09/02/54758.aspx

	Boris Zbarsky [:bzbarsky]
	Comment 12 • 13 years ago

The former doesn't apply because this has nothing to do with painting.  The latter may apply, but the cost of doing the check may well be comparable to the animation cost.  Worth investigating, but in a separate bug.

	Martijn Wargers (dead)
	Comment 13 • 12 years ago

Couldn't this be done by imageAnimationMode on nsidomwindowutils?
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#93

	Brad Lassey [:blassey] (use needinfo?)
	Comment 14 • 12 years ago

qawanted to retest

	Tony Chung [:tchung]
	Comment 15 • 12 years ago

qawanted: martijn will retest.

	Martijn Wargers (dead)
	Comment 16 • 12 years ago

I tested with Fennec trunk on the Galaxy Nexus with this animated gif counter going to 0: http://people.mozilla.com/~mwargers/tests/images/60.gif
It seems the counting down is stopping after 5 seconds or so when it is in the background tab.

	Joshua Mitchell (Inactive)
	Comment 17 • 10 years ago

Issue is resolved - clearing old keywords - qa-wanted clean-up