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>
Implement `size_hint` for more iterators.
```
implement size hint for
more iterators because why
not we like fast things
```
<!-- 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/18494)
<!-- Reviewable:end -->
This patch makes the MallocSizeOf stuff in Stylo work more like the HeapSizeOf
stuff already in Servo, except better. In particular, it adds deriving support
for MallocSizeOf, which will make it easier to improve coverage.
The patch does the following.
- Combines servo/components/style/stylesheets/memory.rs and the heapsize crate
into a new crate, malloc_size_of.
- Forks the heapsize_derive crate, calling it malloc_size_of, so that
MallocSizeOf can be derived.
- Both the new crates have MIT/Apache licenses, like heapsize, in case they are
incorporated into heapsize in the future.
- Renames the methods within MallocSizeOf and the related traits so they are
more concise.
- Removes MallocSizeOfWithGuard.
- Adds `derive(MallocSizeOf)` to a lot of types, in some cases replacing an
equivalent or almost-equivalent hand-written implementation.
- Adds stuff so that Rc/Arc can be handled properly.
style: Avoid scanning the longhand id twice in the fast path of PropertyDeclarationBlock::parse_common
This makes the overhead of this function much lower according to `perf`.
And in general makes sense, removing overhead from the fast path.
<!-- 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/18281)
<!-- Reviewable:end -->
This makes the overhead of this function much lower according to `perf`.
And in general makes sense, removing overhead from the fast path.
MozReview-Commit-ID: 4dJRap9dxNG
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Devirtualize CSS error reporting.
This removes a trait object from the path of reporting a CSS error.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [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/18209)
<!-- Reviewable:end -->
This is a temporary step needed to support Gecko's getKeyframes() API
until we implement bug 1391537. It only takes effect when
a ComputedValues object is supplied and only for longhand declarations.
This is unfortunate, but for now it complicates things, I would like not needing
a ElementData to get the style of an Element in order to fix all the
getDefaultComputedStyle bugs.
MozReview-Commit-ID: LZvsdFEqrDE
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.
Concretely we avoid allocating and scanning a temporary vector of longhands not
yet serialized for each shorthand.
This doesn't save a lot of time in Linux, but I bet it's somewhat important on
OSX.
At least when the longhands aren't custom properties.
We should also look into not serializing the style attribute eagerly when it's
not needed... But a lot of code currently rely on attribute values being
dereferenciables to &str, so that's harder to fix.
We should really look into all those vectors around too, but that's probably
less urgent.
The CSSOM spec forces us to reuse the slot, so we need to conditionally keep the
previous behavior.
This fixes bug 1369198.
MozReview-Commit-ID: LM9mK6ngZ4e
MallocSizeOf is similar to the existing HeapSizeOf trait from the
heapsize crate. The only difference is that MallocSizeOf's
malloc_size_of_children() function takes an additional MallocSizeOfFn
argument, which is used to measure heap blocks. This extra argument
makes MallocSizeOf match how Gecko's memory measurements work, and is
required for Stylo to integrate with DMD.
The patch also introduces a second trait, MallocSizeOfWithGuard, which
is much the same as MallocSizeOf, but with a |guard| argument for the
global style lock.
Finally, the patch uses the new traits to measure a small amount of
Stylo's memory usage.
This enum type used to contain the result of parsing
one CSS source declaration (`name: value;`) and expanding shorthands.
Enum types are as big as the biggest of their variant (plus discriminant),
which was quite big because some shorthands
expand to many longhand properties.
This type was returned through many functions and methods,
wrapped and rewrapped in `Result` with different error types.
This presumably caused significant `memmove` traffic.
Instead, we now allocate an `ArrayVec` on the stack
and pass `&mut` references to it for various functions to push into it.
This type is also very big, but we never move it.
We still use an intermediate data structure because we sometimes decide
after shorthand expansion that a declaration is invalid after all
and that we’re gonna drop it.
Only later do we push to a `PropertyDeclarationBlock`,
with an entire `ArrayVec` or nothing.
In future work we can try to avoid a large stack-allocated array,
and instead writing directly to the heap allocation
of the `Vec` inside `PropertyDeclarationBlock`.
However this is tricky:
we need to preserve this "all or nothing" aspect
of parsing one source declaration,
and at the same time we want to make it as little error-prone as possible
for the various call sites.
`PropertyDeclarationBlock` curently does property deduplication
incrementally: as each `PropertyDeclaration` is pushed,
we check if an existing declaration of the same property exists
and if so overwrite it.
To get rid of the stack allocated array we’d need to somehow
deduplicate separately after pushing multiple `PropertyDeclaration`.
