Now that PropertyDeclaration and AnimationValue have the same discriminants,
that means the trick found in PropertyDeclaration::id can be done in
AnimationValue::id.
By making AnimationValue have the same representation as PropertyDeclaration
and Void variants for non-animatable properties, we know by constructions
that all properties have the same discriminant in both.
This more concrete wrapper type can write a prefix the very first time something
is written to it. This allows removing plenty of useless monomorphisations caused
by the former W/SequenceWriter<W> pair of types.
DOMMatrix needs to convert a specified transform list into a matrix, so
we could rewrite to_transform_3d_matrix by generics for both specified
and computed transform lists.
Besides, we have to update the test case because we use Transform3D<f64> to
compute the matrix, instead of Transform3D<f32>, so the result will be
the same as that in Gecko. Using 0.3 may cause floating point issue
because (0.3f32 as f64) is not equal to 0.3 (i.e. floating point precision
issue), so using 0.25 instead.
In the current implementation, if there is any interpolation error in a matched
transform function pair, we fall-back to use InterpolateMatrix unconditionally.
However, the error could be caused by:
1. mismatched transform function pair
2. matched transform function pair within at least one undecomposable matrix.
Using InterpolateMatrix for case 1 makes sense, however, using InterpolateMatrix
for case 2 does not. According to the spec, we should just report error for
case 2, and let the caller do the fallback procedure. Using InterpolateMatrix
for case 2 will go through more unnecessary code path, and produce more memory
usage and calculation cost, which should be avoidable.
In this patch, we add an extra pass to check if a transform function pair have
matched operations in advance. With this information, we can easily tell whether
the interpolation error in a equal-length transform function pair is caused by
case 1 or case 2. So, we can avoid the unnecessary cost.
Gecko bug: Bug 1399049
Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
Fixes warnings from rust-lang/rust#44229 when `--enable-commonmark` is
passed to rustdoc.
This is mostly a global find-and-replace for bare URIs on lines by
themselves in doc comments.
We use AnimationValue for animation backend to do interpolation,
accumulation, or computing distance. While debugging it, dumping the
property name is not enough. We need to dump the detailed value contained
in it.
We have three different enums to represent slightly different things. Reuse them
properly, and kill some code in the animated_properties module while at it.
MozReview-Commit-ID: 5ZAly8f4lWy
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
`AnimationValue` has its own path for conversion to computed values, so we need
to update `for_non_inherited_property` in the context to match the property
being converted.
I didn't notice any other generic conversions, so hopefully this is the only
missing path.
MozReview-Commit-ID: HskrpMctmYE
At present, we do the fallback discrete animation for non-invertible matrices in
ComputedMatrix.animate(). However, according to the spec, we should fallback to
discrete animation for cases like:
1. animation between transform with single non-invertible matrix
2. animation between transform with matched transform functions that have at least
one non-invertible matrix
2. animation between transform with mismatched transform functions that have at
least one non-invertible matrix.
The current implementation only handles the first case.
Moreover, we already have fallback discrete animation procedures in CSS Animation
and Web Animation, so we should be able to not doing any fallback inside the
Animate trait.
In this patch, we let the animation between non-invertible matrices to return Err().
So, we can propagate the Err() to the callers, and let the fallback discrete
animation procedure stay at the Servo_MatrixTransform_Operate, which is ouside
the Animate trait.
It's just redundant, and I plan to do autogenerate all this stuff, and I don't
want redundant stuff in the manifest.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
This patch replaces the handwritten MallocSizeOf implementation for
PropertyDeclaration with a derived one, which gives much more thorough
measurement.
This requires (a) deriving MallocSizeOf for a *lot* of additional types (most
of which already have `derive(HeapSizeOf)` in Servo builds), and (b)
implementing MallocSizeOf for a few more types in the `malloc_size_of` crate.
These changes would significantly improve the reporting coverage for gmail if
it weren't for the fact that SpecifiedUrl isn't measured due to a lack of
clarity about its fields; that can be fixed as a follow-up once bug 1397971 has
landed.
