We will set the flag when the root node of the traversal has
has-animation-only-dirty-descendants flag or has animation restyle hints.
Also we will use this flag to detect whether we need to trigger CSS transitions
or not.
If an element has only CSS animations we don't need to get transition rule,
and vice versa. This will be used when we implement eRestyle_CSSAnimations
and eRestyle_CSSTransitions.
We create the SequentialTask only if:
* We have no old computed values and we have animation name style in the new
computed values.
* Any animation properties is changed.
* display property is changed from 'none' and we have animation name style.
* display property is changed to 'none'.
In a subsequent patch we skip the SequentialTask if we have no running
animations and the display propery is changed to 'none'.
We use TElement::get_animation_rule to get the animation rules from
Gecko side, which contain the interpolated values of the specific
element and the pseudo type.
Sometimes Gecko eagerly styles things without processing pending restyles first. In
general we'd like to avoid this, but there can be good reasons (for example, needing
to construct a frame for some small piece of newly-added content in order to do something
specific with that frame, but not wanting to flush all of layout). Just handle it.
MozReview-Commit-ID: EjXs0M4855Q
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
The style system never actually does anything with the document. This allows us
to remove a bunch of stubbing on the Gecko side and streamline some things on
the Servo side in future patches.
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.
We don't need this for Gecko, and it's hard to implement in that case because
there's nowhere obvious to put it (we don't plan to create TSDs for non-dirty
nodes, and non-dirty nodes can have dirty children which require the
children_to_process atomic). There are various solutions here, but punting is
the easiest.
We'll need to rethink this if/when we need to do a bottom-up traversal for
Gecko.
It's not possible to implement a Ref::map equivalent method on AtomicRefCell
while having AtomicRefCell implemented on top of RwArc. We could potentially
reimplement AtomicRefCell to be more like RefCell and add a Ref::map equivalent
method, but I (and pcwalton) think we should try just cloning a few extra
Arcs at these callsites instead.
MozReview-Commit-ID: 6H8vAWguO3z
