I still haven't implemented each_part(), so this will do nothing yet.
The cascade order stuff is fishy, I know, and I'll fix in a followup if it's
fine with you. I moved the sorting of the rules to rule_collector, since it
seemed to me it was better that way that duplicating the code, and those
SelectorMap functions only have a single caller anyway.
Differential Revision: https://phabricator.services.mozilla.com/D32647
:root can't change without getting unbound from the tree so no fancy stuff other
than that needed.
This removes a lot of revalidation and attribute invalidation matching from the
Chrome, and looks like it should be a good idea in general.
Differential Revision: https://phabricator.services.mozilla.com/D2462
After bug 1470163 we have some nasty selectors from mathml.css in every page.
We only want to match them against MathML elements.
This patch brings the global revalidation selectors from 14 to 2 in about:blank.
Also halves the ones from XUL documents.
Bug: 1374017
Reviewed-by: heycam
MozReview-Commit-ID: nOVyknNcVm
No cleaner ideas right now that carrying that counter around... Maybe a custom
type may be cleaner?
This makes ApplicableDeclarationBlock a bit bigger. I could probably try to make
the counter a 4 / 5-bit number or something and pack the counter there in the
SourceOrderAndCascadeLevel somehow...
But doesn't seem really worth the churn, and can be done as a followup in any
case. Let me know if you want to block on that.
Bug: 1454162
Reviewed-by: heycam
MozReview-Commit-ID: 1LdW9S4xA6f
We could invalidate in a slightly more fine-grained way, but I don't think it's
worth the churn vs. keeping the special-cases minimal.
Bug: 1452640
Reviewed-by: xidorn
MozReview-Commit-ID: 5DkQrgwg9GW
All TElement's implement Copy, and are just pointers, so the double indirection
is stupid.
I'm going to try to see if removing this double-indirection fixes some
selector-matching performance, and this is a trivial pre-requisite while I wait
for Talos results.
This function is only ever used with one type. This gets rid of the
only use of the `smallvec::VecLike` trait, which we may want to
deprecate. (If we do need to make this function generic in the future,
we can do it using standard traits instead.)
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 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.
This moves us to clear on rebuild, which allows us to remove yet another place
where we track stylist dirtiness.
Bug: 1390255
Reviewed-by: heycam
MozReview-Commit-ID: nihQbUAbh8
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
This shaves a fair amount of time of stylist rebuild.
Most of the extra remaining overhead are memory allocations...
I'll try to get those sorted out next, though fixing that may overlap quite a
bit with the work Cameron is doing in bug 1382925.
MozReview-Commit-ID: 3j2SBY4QnKf
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
