This is really part of the "recalc" rather than the "compute" work. But more to
the point, it lets us early-return on the style-sharing stuff (see the next patch).
We need to do something here to avoid a double-borrow when passing a mutable
StyleContext to match_element. After some discussion on IRC, we decided that
building the bloom filter for this case is probably worthwhile.
This way we'll be able to take different paths for the sequential and parallel
traversals in some concrete cases.
This is a preliminar patch to fix bug 1332525.
It turns out that it's problematic to embed ThreadLocalStyleContext within
LayoutContext, because parameterizing the former on TElement (which we do
in the next patch) infects all the traversal stuff with the trait parameters,
which we don't really want.
In general, it probably makes sense to use separate scoped TLS types for
the separate DOM and Flow tree passes, so we can add a different ScopedTLS
type for the Flow pass if we ever need it.
We also reorder the |scope| and |shared| parameters in parallel.rs, because
it aligns more with the order in style/parallel.rs. I did this when I was
adding a TLS parameter to all these functions, which I realized we don't need
for now.
This allows us to get rid of a bunch of lifetimes and simplify a lot of code. It
also lets us get rid of that nasty lifetime transmute, which is awesome.
The situation with thread-local contexts is still suboptimal, but we fix that in
subsequent patches.
I noticed that our current behavior in ContentRangeInserted is incorrect. Unlike
ContentInserted (where this code lived originally), ContentRangeInserted takes a
start and end element. I'm not sure if we ever take that path for new content that
needs style, but it seemed sketchy. And generally, it seems nice to just always
style new content the same way (though we still need to style NAC by the subtree
root, since it hasn't been attached to the parent yet).
For situations where there is indeed only one unstyled child, the traversal
overhead should be neglible, since we special-case the single-element in
parallel.rs to avoid calling into rayon.
Being more explicit about what we want here also makes us more robust against
the other handful of callpaths that can take us into
nsCSSFrameConstructor::{ContentRangeInserted,ContentAppended}. Currently we
can call StyleNewSubtree on an already-styled element via RecreateFramesForContent,
which triggers an assertion in the servo traversal.
MozReview-Commit-ID: DqCGh90deHH
The primary idea of this patch is to ditch the rigid enum of Previous/Current
styles, and replace it with a series of indicators for the various types of
work that needs to be performed (expanding snapshots, rematching, recascading,
and damage processing). This loses us a little bit of sanity checking (since
the up-to-date-ness of our style is no longer baked into the type system), but
gives us a lot more flexibility that we'll need going forward (especially when
we separate matching from cascading). We also eliminate get_styling_mode in
favor of a method on the traversal.
This patch does a few other things as ridealongs:
* Temporarily eliminates the handling for transfering ownership of styles to the
frame. We'll need this again at some point, but for now it's causing too much
complexity for a half-implemented feature.
* Ditches TRestyleDamage, which is no longer necessary post-crate-merge, and is
a constant source of compilation failures from either needing to be imported
or being unnecessarily imported (which varies between gecko and servo).
* Expands Snapshots for the traversal root, which was missing before.
* Fixes up the skip_root stuff to avoid visiting the skipped root.
* Unifies parallel traversal and avoids spawning for a single work item.
* Adds an explicit pre_traverse step do any pre-processing and determine whether
we need to traverse at all.
MozReview-Commit-ID: IKhLAkAigXE
I realized that I fixed this issue incorrectly when the test failed before. Our design
document specifies that restyle hints must be expanded by the parent before traversing
children, so that we can properly apply LaterSiblings restyle hints. This includes
parents that do not themselves need processing (StylingMode::Traverse).
So we need to preprocess children even in the case where we don't restyle the parent.
On the flip side, we do in fact know whether a child needs processing before enqueuing
it, so we can skip the conservative visit I added before.
MozReview-Commit-ID: AEiRzdsN0h5
This patch introduces infrastructure for the rule tree, and constructs it.
We don't use it yet, nor have good heuristics for GC'ing it, but this should not
happen anymore once we store the rule node reference in the node.
I haven't messed up with memory orders because I want to do a try run with it,
then mess with them.
Take down the ApplicableDeclarationsCache, use the rule tree for doing the cascade.
We also make sure that an element never has an ElementData with ElementDataStyles::Uninitialized,
and eagerly call prepare_for_styling whenever an ElementData is instantiated.
MozReview-Commit-ID: 9YP6eSmdMt0
Instead of maintaining a dummy restyle damage field for text nodes, we can just
perform the necessary parent inheritance and is_changed adjustments on the fly
in ThreadSafeLayoutNode, simplifying the requirements on the style system.
MozReview-Commit-ID: DCqiCRLsLUF
A couple of changes here:
* Remove the option to unset with the dirty bit setters.
* Add an explicit API for setting text node style.
* Hoist has_changed handling into the restyle damage setter and text node style setter.
* Make set_style take a non-Option.
