Do not track images that are not bound to a tree

NEW
Unassigned

Status

()

8 years ago
2 years ago

People

(Reporter: azakai, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 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?
(Reporter)

Comment 1

8 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.
(Reporter)

Comment 2

8 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
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.
Depends on: 1157546
You need to log in before you can comment on or make changes to this bug.