Open Bug 1263019 Opened 8 years ago Updated 1 year ago

Remove nsDocument's image tracking in favor of letting content and frames manage the same state themselves

Categories

(Core :: Layout, defect)

defect

Tracking

()

People

(Reporter: seth, Unassigned)

References

(Depends on 3 open bugs)

Details

After bug 1259281, bug 1261554, and bug 1218990 land, there will no longer be any reason to track images in nsDocument, and indeed doing so adds an unnecessary layer of additional complexity. The replacement mechanisms are as follows:

- Increments and decrements of animation consumers for content images will be handled in nsImageLoadingContent::OnVisibilityChange() and for CSS images in nsFrame::OnVisibilityChange(). The policy we should have is that images get an animation consumer and register with the refresh driver if they're both animated and within the displayport (i.e. their visibility state is IN_DISPLAYPORT). When they transition out of that state, we decrement their animation consumer count and unregister them with the refresh driver.

- Increments and decrements of the lock count for content images will be handled, again, in nsImageLoadingContent::OnVisibilityChange() for content images and nsFrame::OnVisibilityChange() for CSS images. Images should be locked if their visibility state is MAY_BECOME_VISIBLE or IN_DISPLAYPORT, and unlocked otherwise.

- Enabling and disabling image animation globally for the document should just be handled with a flag on the refresh driver; this makes drastically more sense than the current approach.

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: seth.bugzilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.