If the units of two angles being interpolated/added matches, we should preserve
the original unit; otherwise, we fall back to radians. This matches the behavior
of Gecko.
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.
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.
stylo: Bug 1335998 - Handle interpolation and accumulation of mismatched transform lists
These are the interdependent patches of Bug 1335998. We want to do interpolation and accumulation for mismatched transform lists, so introduce ComputedOperation::InterpolateMatrix and ComputedOperation::Accumulation. Both arms store the from_list and to_list, and resolve them until we have the layout information. For the Servo part, we haven't implemented how to read the transform lists in layout/fragment.rs, but I think it would be easy. (related issue #13267)
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1335998](https://bugzilla.mozilla.org/show_bug.cgi?id=1335998)
- [X] There are tests for these changes
<!-- 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/17202)
<!-- Reviewable:end -->
If we set the composite operation to accumulate, we may need to accumulate two
mismatched transform lists, and then to interpolate them. In order to
accumulate two mismatched transform lists, we also need the reference
box information, so use the same idea as that for interpolation. i.e.
use AccmulateMatrix to store it temporarily, and convert it into matrix
later.
We use this arm to store the interpolated result of two mismatched
transform lists, and we resolve it until we know the reference box size
(on Gecko side). The conversion from ComputedOperation::InterpolateMatrix
to eCSSKeyword_interpolatematrix will be implemented later in this patch series.
Without this patch anim-css-strokewidth-1-by-pct-pct.svg (and possibly
others) fails because we calculate the result as 'calc(0px + 10%)' and
we don't support calc on stroke-width (yet) so the rendered result is
incorrect.
As a more thorough fix, we should make the zero-value for
LengthOrPercentageOrNumber a zero *number* (instead of a zero length)
but that won't work yet since we don't support animating between
stroke-widths with units and those that don't (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1369614). Regardless of
that, we still shouldn't introduce calc in order to add a zero value
using the LengthOrPercentage type, so this change is still needed.
Although there are no specific tests for this yet if any code does try
to perform addition or accumulation with a font-stretch value it will
likely fail the bounds check in the Into trait. To avoid that this
patch provides an basic implementation of add_weighted for font-stretch
that should work correctly with portions whose sum is outside the [0.0,
1.0] range.
