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.
This requires a little bit of gymnastics since it has to add the inverse
of tests, since the is-a-reset-struct tests originally added in patch 8
were made unconditional in patch 9, and with this backout we now want to
execute the code only for inherited structs.
This also doesn't back out the cleanup to use NS_STYLE_INHERIT_BIT() for
constants rather than nsCachedStyleData::GetBitForSID.
This backs out the part of bug 1209603 whose speed I was concerned about.
--HG--
extra : commitid : 6BWdXCpywlU
extra : rebase_source : 15597857a721a3a399432c8454ecfc7b789e5e2d
This is another case similar to the problem fixed in bug 1209603 patch 9.
This should make things faster by caching structs on the style context
more reliably.
--HG--
extra : commitid : GdalxPoI0wr
extra : rebase_source : 103e678a237f723b386b517d478e70214a75467e
This means we obey the invariant that if we've requested an inherited
struct on a context, that struct will be cached on the style context. I
believe bug 527977 intended to do make us obey this invariant, but it
missed the case where nsRuleNode::GetStyle* found cached data already on
the rule node, and the case where nsRuleNode::WalkRuleTree found a
usable struct higher in the rule tree.
Without this change, patch 10 will not function correctly for inherited
structs when we encounter this case, and will cause assertions in
dom/base/test/test_bug560780.html due to triggering style change hints
on text nodes that inherited a color struct from a parent on whose rule
node the struct was stored. (It may also have caused some of the other
test failures.)
This should be a clear performance improvement, since the path that's
being slowed down by the added work in this patch will, with the patch,
now only execute once because of that work.
--HG--
extra : commitid : 5hueOZihqNx
I'm a little worried about the performance of the change to
nsRuleNode::GetStyle*, which sets a bit on the style context every time
a struct getter goes through it. It's not obvious how that compares to
the performance benefit from patch 10.
--HG--
extra : commitid : J2XERgJ7mh2
The only substantive change here, apart from a few variables changing in
size from uint16_t to uint8_t, is FontFaceSet's use of SheetType::Unknown
(0xFF) instead of 0 for FontFaceRecords for script-created FontFaces.
AllocateByObjectID() is infallible. Therefore the |operator new| of nsFrameList,
nsLineBox and nsRuleNode are too, as is nsRuleNode::CreateRootNode().
The patch also removes a couple of comments duplicated in both .h and .cpp
files.
--HG--
extra : rebase_source : 0b9e195fd547fdd53ddad7bb461ff5f5c2016fce
They're not needed now that there is (temporarily) PLDHashTable2, which has an
initializing constructor and a destructor.
--HG--
extra : rebase_source : 78d3eeb326935ad7a19e3bdf9b2092eb2a4208a7
This includes removing:
* the box property directional source constants
* the CSS_PROPERTY_DIRECTIONAL_SOURCE property flag
* the CSS_PROPERTY_REPORT_OTHER_NAME property flag
* nsCSSProps::OtherNameFor
* methods on the CSS parser to parse directional box properties and set
the old *-source and *-value properties
* the resolution of logical and physical properties in nsRuleNode during
style computation, since that's now done as part of the cascade in
nsCSSExpandedDataBlock::MapRuleInfoInto
This includes removing:
* the box property directional source constants
* the CSS_PROPERTY_DIRECTIONAL_SOURCE property flag
* the CSS_PROPERTY_REPORT_OTHER_NAME property flag
* nsCSSProps::OtherNameFor
* methods on the CSS parser to parse directional box properties and set
the old *-source and *-value properties
* the resolution of logical and physical properties in nsRuleNode during
style computation, since that's now done as part of the cascade in
nsCSSExpandedDataBlock::MapRuleInfoInto
This is similar to bug 1038488, which did the same for style structs.
This means the entire path from frame to style struct should be
allocated using frame IDs or object IDs.
This re-parses property values at computed value time if
they had a specified value that was a token stream. We add
a function nsRuleNode::ResolveVariableReferences that looks
at all the values in the nsRuleData and calls in to a new
nsCSSParser::ParsePropertyWithVariableReferences function if they have a
token stream value.
We add a nsCSSExpandedDataBlock::MapRuleInfoInto function that will
take the re-parsed property value and copy it back into the nsRuleData.
nsRuleNode::ResolveVariableReferences returns whether any variables
were attempted to be resolved, so that nsRuleNode::WalkRuleTree wil
recompute the rule detail in case any became 'inherit'.
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.
