Propagate changes in custom properties' computed values to descendants
If ComputedValues.custom_properties differs between the old and new
ComputedValues, indicate that we have to propogate changes to
descendants by setting child_cascade_requirement to
MustCascadeDescendants in cascade_primary.
style::matching::TElement::cascade_primary already calls
accumulate_damage, which eventually calls
ServoRestyleDamage::compute_style_difference in order to check if other
properties' computed values changed. If any of those change, we signal
that we need to propogate changes for inherited properties.
With Properties & Values, some custom properties will not be inherited,
and we will need to revisit this.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#17283
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17284)
<!-- Reviewable:end -->
Now we have AnimatableLonghand (to do with animatability) and
TransitionProperty (to do with transitionability), we should move
nscssproperty_id_is_animatable to be part of the former group.
Currently properties that are discretely animated cannot be
transitioned. Now that TransitionProperty should only be used for
transitions, we can redefine it to treat non-transitionable properties
as unsupported. This should allow us to simplify the code and make it
more self-documenting (e.g. making TransitionProperty actually relate to
transitions).
In the next few patches we move all non-transition related code over to
using AnimatableLonghand instead of TransitionProperty. This will allow
us to re-purpose TransitionProperty to represent only properties that
can be transitioned (i.e. excluding discrete properties) as well as
simplifying the code by removing the need to deal with shorthands and
the "all" value in places that do not need to handle those values.
I saw this function appear in the profiles at #17329.
It was under set_device, which isn't a Stylo path, but probably worth there
anyway.
This reduces the reported overhead of RulesIterator::next in perf from ~8% to
0.46%
This type, which we will use in the next patch in this series, can
represent only longhands whose animation type is not "none". By
introducing this type, we can later restrict the meaning of
TransitionProperty to only cover properties whose animation type is not
"none" OR "discrete" (since currently CSS transitions should not animate
properties whose animation type is discrete). Doing so will also mean
that CSS transitions ignore the 'display' property by default.
Furthermore, introducing this type will allow the animation code to
clearly document when a property is allowed to be a shorthand or
unanimatable property and when it is expected to be an animatable
longhand. This, in turn, will allow us to remove a few
no-longer-necessary checks and simplify the code.
This allows simplifying the code somewhat and means we can ignore
unanimated shorthands a little sooner. Furthermore, it removes the odd
inconsistency where TransitionProperty only included animatable
longhands but allowed all shorthands regardless of whether or not they
were animatable.
