Unrecognized property names should still be kept in the list to preserve
matching of indices (e.g. that the Nth property should associate with
the Nth duration)
Converting to CSSPixels caused us to lose precision and the sign of
signed zeroes.
The values we resolve against in Length::ResolutionContext are still
themselves rounded too early but this is in the right direction.
Doing trigonometric calculations with floating point numbers can
introduce small inaccuracies. This meant that we would sometimes
incorrectly generate a 3d rather than 2d matrix for the resolved value
of `transform`.
Gains us 3 WPT tests.
In this case, we should just draw a line from the last point in the
path to the start point. Previously, a division by zero caused nothing
to be drawn.
We implemented repeating linear gradients by expanding a vector of color
stops until the entire range was covered. This is both a bit wasteful
and caused Skia to draw corrupted gradients to screen whenever the total
amount of color stops and positions exceeded 127.
Instead of doing that, use the original color stops for the shader and
repeat it instead of clamping it. We need to do a bit of math to project
positions correctly, but after that the shader repeats itself nicely.
While we're here, calculate the gradient's length and the center point
as floats instead of ints, yielding a slight but noticeable improvement
in gradient rendering (see the diff on the zig zag pattern in
css-gradients.html for an example of this).
We prime `color_stop_list_with_expanded_repeat` with the input
`color_stop_list`, so we don't actually need to copy the stops for the
first iteration. This didn't result in graphical glitches, but these
entries were unnecessary irregardless.
We could never hit the #else branches for some of these methods, because
we already relied on having __builtin_*_overflow() readily available in
earlier methods.
multiplication_would_overflow() with three arguments was only used in a
test, so let's get rid of that as well.
Since we now have access to the `AbstractElement` through the
`ComputationContext` we can just set the flag that this element relies
on tree counting functions directly, no need to pass this struct around.
Passing the `AbstractElement` rather than the
`TreeCountingFunctionResolutionContext` allows us to only compute the
resolution context when necessary (i.e. when we actually need to resolve
a tree counting function)
Previously when one child of an element changed we would iterate over
every child to check whether they needed to be invalidated because they
relied on tree counting functions.
We now skip this in most cases by only doing it when at least one child
relies on tree counting functions.
