The basic idea here is as follows:
* Rule nodes are reference-counted, but releasing them adds them to a linked
list rather than freeing them. This allows for the reuse that motivated the
original GC scheme.
* We get rid of the marking, and instead rely on the reference count.
* Sweeping no longer requires a complicated traversal. We just pop items
off the free list until it's empty. When a child is destroyed, its parent
may go onto the free list.
* We remove special handling for the root node, and use a regular reference-counted
edge from the style set.
* The free list automatically asserts that it's empty (meaning all nodes have been
freed) in its destructor, which runs when the style set is destroyed.
* We get rid of the list of style context roots on the style set. We still need
a count though, because of the HasCachedStyleData check.
The basic idea here is as follows:
* Rule nodes are reference-counted, but releasing them adds them to a linked
list rather than freeing them. This allows for the reuse that motivated the
original GC scheme.
* We get rid of the marking, and instead rely on the reference count.
* Sweeping no longer requires a complicated traversal. We just pop items
off the free list until it's empty. When a child is destroyed, its parent
may go onto the free list.
* We remove special handling for the root node, and use a regular reference-counted
edge from the style set.
* The free list automatically asserts that it's empty (meaning all nodes have been
freed) in its destructor, which runs when the style set is destroyed.
* We get rid of the list of style context roots on the style set. We still need
a count though, because of the HasCachedStyleData check.
Having a non-null mInstanceOwner corresponds to when registration
normally happens (from nsPluginInstanceOwner::SetFrame), and it's
disconnecting the instance owner that leads to unregistration.
MozReview-Commit-ID: 3X15t9zoXIj
The previous annotations only checked if the re-entrancy happened via DecrementVisibleCount.
The check in RebuildApproximateFrameVisibility is not needed because we add a check in DoUpdateApproximateFrameVisibility.
The check in ClearApproximatelyVisibleFramesList is not needed because we add checks in DoUpdateApproximateFrameVisibility and Destroy. The other caller, ClearApproximateFrameVisibilityVisited, is covered because it is only called from DoUpdateApproximateFrameVisibility.
MozReview-Commit-ID: 5UaOQ4l50wP
While processing restyles and starting transitions, we may trigger
a call to EffectCompositor::UpdateCascadeResults which may, in turn, call
EffectCompositor::RequestRestyle with RestyleType::Layer, which ultimately
results in a call to RestyleManager::IncrementAnimationGeneration().
Typically, nsTransitionManager::StyleContextChanged compares the animation
generation on its collection with that of the restyle manager and uses this
to ignore the restyle that it generates. However, given the sequence of events
above, that check may no longer help since the restyle manager's animation
generation will be out of step. As a result,
nsTransitionManager::StyleContextChanged will fail to ignore a subsequent
and redundant restyle. With certain combinations of content, this can mean that
restyles are posted in such a manner than an infinite cycle of restyles ensues.
This patch causes RestyleManager to ignore calls to IncrementAnimationGeneration
when it is already processing restyles such that the animation generation is
only ever updated once per restyle. This makes the check for a matching
animation generation in nsTransitionManager::StyleContextChanged work as
expected, preventing us from generating needless transitions which can produce
this endless loop.
MozReview-Commit-ID: 9HYDrknKPAI
This is needed because blending for nsDisplayBackgroundImage items will soon
happen outside of nsDisplayBackgroundImage::Paint, it will be done by an
nsDisplayBlendMode item that wraps the nsDisplayBackgroundImage item.
MozReview-Commit-ID: 20cILOGVFEG
