The code that uses it is of dubious utility, fwiw, but some of it is used on
Servo, so I'll kill that separately.
Bug: 1412486
Reviewed-by: xidorn
MozReview-Commit-ID: KauvXX32zLM
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`.
This fixes the fishy TransitionProperty mapping which I complained about in my
previous refactor.
Turns out that those properties could only be longhands, and thus the expansion
we did before that (and which I removed) was correct.
This fixes the bug by moving back to the previous correct behavior but using the
correct types.
The optimization to avoid creating a HashSet if we're transitioning all
properties or had no existing transition is removed since now we're creating a
LonghandIdSet, which is cheap, and that was only a performance optimization.
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>
We were using the wrong MatchingMode and flags setter just because we didn't
bother threading them down.
This patch fixes the issue seen with the video controls.
MozReview-Commit-ID: Il1WOzRDxI1
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
This avoids grabbing the document when values that inherit from the body,
whatever that means, aren't under the body.
In that case we'll get a semi-random value, but that's also mishandled by Gecko
anyways (and probably Blink, though haven't tested), and doesn't really make
much sense.
This avoids grabbing the document when values that inherit from the body,
whatever that means, aren't under the body.
In that case we'll get a semi-random value, but that's also mishandled by Gecko
anyways (and probably Blink, though haven't tested), and doesn't really make
much sense.
The only reason why we had the `existing_style_for_style_damage` bit is to apply
some optimizations that we don't have anymore.
I still want to reintroduce a few of them, at least for the non-eager
pseudo-element case... But I think I won't need this at all.
This allows us to remove a fair amount of Gecko code too.
Now that we do process normal traversal even in the case of throttled animation
flush so that we don't need to do special handling for the case.
Note about the comment in has_current_styles():
the remaining animation hints is not caused by either this patch or the
previous patch in this patch series, it's been there in the first place, but
it should be fixed somehow later. See bug 1389675.
MozReview-Commit-ID: JojHufxNCiS
Deduplicating code is nice, and it will help us when we make the bit
propagation more complicated in upcoming patches.
MozReview-Commit-ID: KIQnNJVayrM
The buggy animation handling isn't a regression, since currently we pass
UnstyledChildrenOnly in those cases, which blocks the animation traversal
in Servo_TraverseSubtree.
In general I really wanted to handle these two paths together. But there's
enough broken with the NewChildren path that I wanted to scope the buginess
as tightly as possible. And I really need to separate the handling here from
StyleDocument() to make the restyle root stuff work.
MozReview-Commit-ID: 9F0mcQl7AAX
When display style is changed from 'none' to other in animation-only restyle
we need to resolve descendant elements' style that were in the display:none
subtree.
Three possible ways to resolve the descendant elements' style;
1) Traversing unstyled elements in animation-only restyle
We can't simply traverse unstyled elements in the animation-only restyle
since when we decided to traverse the unstyled elements we don't know yet
the elements will be initially styled or are in display:none subtree. It
will result that the new elements are styled in animation-only restyle,
it's undesirable.
2) Creating a SequentialTask and resolve the descendants' style with
ServoStyleSet::StyleNewSubtree()
We can't resolve the descendants' styles with ServoStyleSet::StyleNewSubtree()
in SequentialTask since at the moment we are still in servo traversal (i.e.
sInServoTraversal is true). That means AutoSetInServoTraversal fails
in PrepareAndTraverseSubtree().
3) Creating a SequentialTask and set restyle subtree hint and defer descendants'
restyle in a subsequent normal traversal
Note that, when we process throttled animations flush, we don't process
normal traversal so the descendants will not be traversed until normal
restyle happens but it will not be a big problem since it's really rare
that user clicks display animation element just at the right moment when
display property changes from none to other. Also, if it will be really
a problem, we should process *only* transform animations on the compositor,
it's ideally right thing to do. Display property never runs on the
compositor.
This patch takes the third approach.
