This is because patch 4 now uses AddAndRemoveTransform hints for changes
that are other than adding and removing a transform. There's still a
little bit of transform-related stuff there too (which I did make
conditional in patch 2).
--HG--
extra : commitid : DF2FByhoo7E
I'm fed up with having to use the NS_*Hint functions, and I also have
trouble reading/writing some of them since I don't remember the order of
parameters.
(At some point I think we should convert existing callers, but I don't
plan to do that here.)
This cleans up after bug 984226, which introduced
CHILDREN_AND_PARENT_CHANGED to deal with the facts that:
(1) most properties whose changes yield UpdateOverflow style hints
imply that an element's overflow area may have changed, and
propagation to ancestors can stop without updating the element's
parent if the element's own overflow area didn't change.
(2) a few properties whose changes yield UpdateOverflow style hints
actually don't change the overflow area of the element on which the
property changed, but instead change that element's overflow area
on the element's parent.
Having two separate hints means that we don't have to do the extra work
of always updating the parent's overflow area (when the child's overflow
area didn't actually change) for the properties in category (1), and we
don't have to do extra work of updating the element's own overflow area
for properties in category (2).
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 an additional bit on nsRestyleHint that says that the restyling
operation should also perform all the work needed to switch between
style-without-animation and style-with-animation (based on
nsPresContext::IsProcessingAnimationStyleChange). These concepts will
go away in bug 960465.
Note that we don't want this behavior for the animation-only style
update code (bug 996796, etc.), and I wanted to make this explicit so
that it was clear when it was happening, and so that it was clear what
code should be removed when we git rid of it.
This is the workaround needed to land bug 977991 prior to bug 960465.
(I think there's also a minor dependency in the other direction, so we
need a workaround one way or the other.)
Note that this depends on bug 1057231.
This allows posting a restyle that says that only the rule(s) from the
StyleAttrSheet cascade level will be replaced, which avoids running
selector matching.
Part 4 will ensure that we only invoke this code for element styles (and
not pseudo-element or anonymous box styles). Despite that, I prefer
having the runtime check here as well given that it's a very simple way
to ensure we don't do something silly that might have security
implications.
This avoids having to cast back to nsRestyleHint after using bitwise
operators, and allows |= (etc.).
(In the future we should consider converting nsRestyleHint, and probably
also nsChangeHint, to use MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS.)
This allows posting a restyle that says that only the rule(s) from the
SVGAttrAnimationSheet cascade level will be replaced, which avoids running
selector matching.
This is needed to land bug 977991 prior to landing bug 960465, since
that requires replacing all levels that contain animations.
(I'll rename this to match the name determined in bug 1057231.)
This is the start of a refactoring of the existing code in
CommonAnimationManager, nsTransitionManager, and nsAnimationManager,
which will be removed in later patches (after patches in between cause
this code to be used instead of the current code).
But it also handles interesting cases more correctly, such as cases
where style context parents are unusual.
FIXME: It would be nice to add tests for these cases, but they're mostly
pretty obscure (e.g., a transition of 'transform' that's affected by
inheriting 'transform' from ::first-line), so I'm not treating it as a
priority right now.
- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED),
the overflow areas of the children have changed and the parent have changed
(CHILDREN_AND_PARENT_CHANGED), or if only the transform has changed
(TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
- OverflowChangedTracker::AddFrame now accepts an enumerated type parameter to
indicate if the overflow areas of children have changed (CHILDREN_CHANGED) or
if the transform has changed (TRANSFORM_CHANGED).
- OverflowChangedTracker::Flush no longer falls back to calling
nsIFrame::UpdateOverflow when a frame lacks a PreTransformOverflowAreas
property.
- Added an additional change hint, nsChangeHint_ChildrenOnlyTransform, which
results in TRANSFORM_CHANGED being passed in to
OverflowChangedTracker::AddFrame.
- In nsIFrame::FinishAndStoreOverflow, the passed in overflow is now stored as
the InitialTransformProperty for elements that are IsTransformed().
- Partially corrected Bug 926155, by only calling
OverflowChangedTracker::AddFrame on parents of the sticky element during
StickyScrollContainer::UpdatePositions, using CHILDREN_CHANGED.
This propagates the non-inherited (in the nsChangeHint sense, not the
CSS inheritance sense) parts of the parent's change hint through
ReResolveStyleContext so that we can use them in
nsStyleContext::CalcDifference. In the cases where we don't know the
parent's hint, we assume the worst, that all the non-inherited hints
were present in the parent's style change.
This should be a significant performance improvement handling simple
style changes (such as a style attribute change setting a non-inherited
property) on elements with large numbers of descendants that have data
in ForceCompare structs that can't be stored in the rule tree (for
example, margins or widths in em or rem units).
This is in preparation for adding an additional caller.
nsChangeHint_NonInherited_Hints will be reintroduced in patch 6, but as
the maximum set of such hints rather than the minimal set, and with the
less confusing name nsChangeHint_Hints_NotHandledForDescendants.
This patch adds a change hint to signal that one of the offsets on a
frame has been changed. When processing the hint, we do one of the
following things based on the position property of the frame.
* For static frames, we ignore the offset changes completely, as they
will not change the layout.
* For relative positioned frames, this patch refactors the
nsHTMLReflowState::ComputeRelativeOffsets function so that it can be
used from other callers, and it uses that to compute the new relative
offsets, and uses the offsets computed previously to compute the new
position of the frame.
* For absolute positioned frames, we set up a fake parent reflow state
object, and then we create a new reflow state object for the frame in
question. This setup is similar to what nsFrame::BoxReflow does.
Once we have the new reflow state object, we use it to compute the
absolute offsets, and then we use the computed offsets to set the new
position of the frame. The offset computation is similar to what
nsAbsoluteContainingBlock::ReflowAbsoluteFrame does. In some cases
where it is possible for the dimensions of the frame to change based
on the offset changes, we fall back to a full reflow.