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
In the Gecko case, this style source would be the style context. In the servo
case, it will be always the computed values.
We could optimise this further in the case of stylo (from three FFI calls to
one) if we use an API of the form CalcAndStore(node, new_cv). But that would
imply borrowing the data twice from Servo (we also have borrow_data_unchecked
fwiw, but...).
There's a bit of flickering when unpausing where the node has the original
state, but I'm not totally sure where it comes from, posibly from
PropertyAnimation returning None due to no styles changing?
There are a few shortcomings, for example:
* We don't do the same as other browsers when some properties are not specified
in some of the keyframes, though this is easy to work out (though a bit more
expensive in the sense that we should apply all the previous keyframes' style
instead of just the previous and the next.
* To trigger the initial animation, a restyle is necessary. Should be easy to
do an initial restyle off-hand or something like that, but for now this is
worked-around adding a :hover rule to the node.
Also, the animation is resetted when the node is hovered. That's a bug, but
is probably not so difficult to test.
* A few things, mainly animation-direction, are not supported yet, but
shouldn't be that hard to support.
Still a lot of work to do, but I think this approach might be ok.
There's some maths I've done wrong, but it DOES animate some things, though
they're only triggered past the first restyle, and we probably have some
duplications where the animations arrive to layout.
Anyway, got to go.
It's a pointless abstraction that propagates the obsolete chan terminology,
swaps the order in which the sender and receiver are returned, and hides a
source of panics.
We do a few things-here:
* Hoist non-layout-dependent fields in SharedLayoutData and LocalLayoutData into style/.
* Hoist parts of css/matching.rs into style/.
* Hoist parts of layout/animation.rs into style/animation.rs.
* Remove the duplicated-but-slightly-different definition of OpaqueNode.
animations complete or are interrupted.
This adds a new pair of reader-writer locks. I measured the performance
of style recalculation on Wikipedia and the overhead of the locks was
not measurable.
Closes#7816.
There were two problems here:
(1) The animation state update function was only called when nodes were dirty or there were new animations.
(2) When all animations for a node expired, the entry from the hash table was not removed.
The result was that once an animation began, the compositor would be running as fast as it can forever.
Fixes#7721.