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

If an Image is preloaded, using something like

  x = new Image();
  x.src = URL;

then it will be loaded, and TrackImage called. So we will run its animation, even if it isn't being shown anywhere.

We should only track the image if the image element is bound to a tree.

The approach I suggest is outlined in this patch (which does a few other things too),

https://bugzilla.mozilla.org/attachment.cgi?id=503241&action=diff

Basically,

1. Take note when we are bound. I can't find a good way to do this, so I added mBoundToTree in that patch. Is there a better way?
2. Not track the image if not bound.
3. Call TrackImage when binding, and UntrackImage when unbinding.
4. Track only the current request, and not the pending one, and be careful about tracking exactly once and always untracking (using mTrackedRequest - I suspect we called track more than once per image before).

See a few relevant comments here: https://bugzilla.mozilla.org/show_bug.cgi?id=594771#c52

Is the approach described above acceptable?

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

An alternative to this is to have several kinds of animation consumers/locks. So when not bound, one type of lock would be taken - just enough for preloading to work. When bound, another lock would be taken - enough to also actually render/animate. Perhaps other types are needed too.

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

To clarify, the point of multiple lock types is to enable the following:

1. When preloaded, we remain in memory but do not animate
2. When shown, we animate
3. When in a background tab, we freeze

	Seth Fowler [:seth] [:s2h]
	Comment 3 • 9 years ago

This is implemented in bug 1157546. (Indeed, the condition is stronger: we need to not only be bound to the tree, but the frame must be visible.)

I'm pretty sure it also worked before then, actually. But rather than verify that, I'll just make this blocked by bug 1157546, which should land very soon.