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)
Core
Layout
Tracking
()
NEW
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.
Comment 1•2 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: seth.bugzilla → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•