Two functions are added:
* HasSameCachedStyleData, which compares a style struct pointer in two
style contexts, and
* HasCachedInheritedStyleData, which checks to see if the bit in mBits
is set.
This patch also moves the static methods defined on nsStyleAnimation so that
they are part of StyleAnimationValue class.
Renaming nsStyleAnimation.h to StyleAnimationValue.h is performed in a separate
patch to simplify the diff (since some tools may not handle file renames
elegantly).
This makes updates work correctly when variable values change.
Rather than handling nsStyleVariables with a DO_STRUCT_DIFFERENCE,
we explicitly compare the two nsStyleVariables objects in
nsStyleContext::CalcStyleDifference before looking at the other
style structs. This is because we need to force those other
style structs to be compared if variable values are changing.
nsStyleVariables::CalcDifference still returns 0, since the change in
variable values themselves doesn't require any updates.
This adds an nsStyleVariables on which computed variable values
will be stored. We don't actually have any properties assigned to
nsStyleVariables; eCSSPropertyExtra_Variables which we added earlier
isn't a real property. To avoid compiler errors for gVariableFlags
being a zero length array, we stick a dummy entry in there.
nsRuleNode::ComputeVariablesData does nothing for the moment.
nsStyleVariable nsChangeHint calculations always return 0, as later
we will compare the actual properties that reference variables to
see what changes are required for them.
This bumps up nsStyleContext::mBits to a uint64_t so that it can fit
another style struct. If we're going to need to keep at least 27 style
structs, it might be better to split mBits up into two uint32_ts: one
for the flags and one for the style struct bits.
Clang and GCC probably MSVC are not able to unalias list because they don't
realize that mEmptyChild and mChild can't alias mNextSibling and mPrevSibling.
If we explicitly dereference list we get better code, saving 3 instructions
with clang.
Except for the changes in:
layout/generic/nsIFrame.h (part)
layout/style/nsComputedDOMStyle.h (all)
layout/style/nsRuleNode.cpp (part)
layout/style/nsStyleContext.cpp (part)
layout/style/nsStyleContext.h (part)
(see patch 3b in the bug), this patch was written with the sed script:
s/\<GetStyle\(Font\|Color\|List\|Text\|Visibility\|Quotes\|UserInterface\|TableBorder\|SVG\|Background\|Position\|TextReset\|Display\|Content\|UIReset\|Table\|Margin\|Padding\|Border\|Outline\|XUL\|SVGReset\|Column\)\>/Style\1/g
This makes it conform to our convention that getters returning pointers
that can never be null do not begin with "Get".
nsStyleContext's rule node is never null because we require a rule node
in order to construct a style context.
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.
