This patch is not needed to fix the bug, but it seems like it's probably
desirable. It's not needed for this bug because
MaybeReframeForBeforePseudo and MaybeReframeForAfterPseudo are already
called (by ElementRestyler::RestyleChildren) on only the first and last
continuation or ib-split sibling with the same style. So this patch
should only actually change anything for cases like a block-in-inline
split whose initial inline part is inside of a ::first-line (where
different parts of the block-in-inline split chain have different style).
Since the symptom of this bug is (once patch 6 is in the tree) only
causing extra reframes, it can only be tested using the new API (from
bug 1115691) for observing reframes. I confirmed that the test for this
bug fails without the patch and passes with the patch (as noted by the
removal of its todo annotation).
For some kinds of changes we need to update the layer tree even though there is
no change to style. For example, if an animation is paused via the Web
Animations API, we need to remove the animation from the layer even though the
style will not change.
This patch detects such changes by making ElementRestyler check for an
out-of-date animation generation on layers. This is complicated by the fact that
we currently maintain *two* animation generation numbers: one for the set of
animations and one for the set of transitions, but we only have *one* animation
generation number on each layer. This is a known issue (bug 847286).
As a result, until bug 847286 is fixed, we need to be careful to compare against
the greater of the two numbers.
Until we get rid of animation phases in bug 960465, we need to ensure
we're producing style data for the correct animation phase. This makes
this optimization slightly less beneficial until then.
Bug 931668 added the eRestyle_ForceDescendants case for all cases that
go through RebuildAllStyleData, but there is another case that calls
DoRebuildAllStyleData directly, and we should cover that too.
This is needed because when we're rebuilding the rule tree, we need to
create new style contexts for all frames.
I don't know of any bugs caused by this, but it seems worth fixing.
This is just moving one bit of data from the pres context without any
logic change. But given the other refactoring, it seems to make more
sense here now.
The MOZ_DEBUG_RESTYLE_STRUCTS environment variable can be set to a comma-
separated list of style struct names. When restyle logging is enabled,
this will cause the style context tree -- showing cached style struct
pointers for those structs specified -- to be logged before each
individual restyle is processed. It will also show the struct pointer
values involved when swapping structs between style contexts.
For example, set MOZ_DEBUG_RESTYLE_STRUCTS=Font,UserInterface to show
the cached nsStyleFont and nsStyleUserInterface pointers on the style
contexts involved in the restyle process.
Set the MOZ_DEBUG_RESTYLE environment variable and every restyle will have
detailed logging printed to stderr. By default, restyles for animations are
not logged; you can include them by also setting MOZ_DEBUG_RESTYLE_ANIMATIONS.
If you wish to limit restyle logging to a particular change, you can call
nsPresContext::StartRestyleLogging() and nsPresContext::StopRestyleLogging()
at appropriate points. (You might want to add a couple of helper methods
temporarily on nsIDocument and then expose them to your page with Web IDL
to make them easier to call.) You do not need to have set MOZ_DEBUG_RESTYLE
for this to work.
Set the MOZ_DEBUG_RESTYLE environment variable and every restyle will have
detailed logging printed to stderr. By default, restyles for animations are
not logged; you can include them by also setting MOZ_DEBUG_RESTYLE_ANIMATIONS.
If you wish to limit restyle logging to a particular change, you can call
nsPresContext::StartRestyleLogging() and nsPresContext::StopRestyleLogging()
at appropriate points. (You might want to add a couple of helper methods
temporarily on nsIDocument and then expose them to your page with Web IDL
to make them easier to call.) You do not need to have set MOZ_DEBUG_RESTYLE
for this to work.
This is needed because patch 1 and patch 3 did not add a mechanism that
allows restyling pseudo-elements, which would be substantially more work
and very little use (since the only case in which they have style
attributes is for our internal use on the ::-moz-color-swatch
pseudo-element).
RestyleUndisplayedChildren does not need the same fix because it's only
used on elements, and never on pseudo-elements or anonymous boxes.
We don't do struct swapping if either the old or new style contexts are
shared, since we can't guarantee that such a change will be valid for
all frames that use the shared style context.
--HG--
extra : rebase_source : 10f7c90422de23b119287ba478d36433423440da
