| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crate.
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D33353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is indeed the most common case according to a bit of measurement.
A non-atypical example from GitHub for example:
> Rule tree stats:
> 0 - 340
> 1 - 1403
> 2 - 28
> 3 - 8
> 4 - 2
> 6 - 1
> 7 - 3
> 8 - 2
> 12 - 2
> 14 - 1
> 41 - 1
> 45 - 1
> 67 - 1
> 68 - 1
Differential Revision: https://phabricator.services.mozilla.com/D33351
|
|
|
|
|
|
|
|
| |
trace-level logging.
This is useful to analyze the shape of the rule tree at a glance.
Differential Revision: https://phabricator.services.mozilla.com/D33350
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove unused code (4/4)
<!-- Please describe your changes on the following line: -->
Fourth and final PR in a series of PRs to remove unused/dead code from servo, powered by an (upcoming) tool of mine. Please take a look and tell me if you want to keep something.
* First PR: #23477
* Second PR: #23498
* Third PR: #23499
Shortstat of the combined PR series:
```
47 files changed, 7 insertions(+), 805 deletions(-)
```
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they only remove dead code
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- 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/23532)
<!-- Reviewable:end -->
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
node children.
I need to profile this a bit more, but talos was pretty happy about this, and it
solves the known performance issues here such as the test-case from bug 1483963
for example. This also gets rid of a bunch of unsafe code which is nice.
This still keeps the same GC scheme, removing the key from the hashmap when
needed. I kept those as release assertions, but should probably be turned into
debug-only assertions.
Differential Revision: https://phabricator.services.mozilla.com/D6801
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We cannot compile with just feature(gecko + debug_assertions), since that's how
debug rusttests get compiled and they don't have the refcount logging stuff.
We were getting away with it for the pre-existing usage of the style crate,
because it wasn't used during any test and presumably the linker didn't
complain. But servo_arc is definitely used in tests.
Differential Revision: https://phabricator.services.mozilla.com/D32691
|
|/
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D32173
|
|
|
|
|
|
| |
A patch of mine that makes us measure the rule tree more often triggers this.
Differential Revision: https://phabricator.services.mozilla.com/D26595
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inserted.
Without this change an assertion checking IsInStyleRefresh() in
EffectCompositor::PostRestyleForAnimation will be hit when we call
FindAnimationsForCompositor from RestyleManager::DoProcessPendingRestyles
that will be introduced in a subsequent commit in this series.
I wrote a crash test which causes an assertion in KeyframeEffect::CanThrottle()
without the subsequent commit, but we need more work in display item stuff to
make the assertion won't happen (bug 1508466).
Differential Revision: https://phabricator.services.mozilla.com/D12368
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Most of the change is moving sets around to be static functions on
LonghandIdSet. I think I like that pattern, but I can also make the new set a
global static and add mako code to be `pub` or something.
Though I think the LonghandIdSet::foo().contains(..) pattern is nice to read :)
Differential Revision: https://phabricator.services.mozilla.com/D10653
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D10017
|
|
|
|
| |
StrongRuleNode is really Sync.
|
|
|
|
| |
Differential Revision: https://phabricator.services.mozilla.com/D6034
|
|
|
|
|
|
|
| |
There are a few mentions of nsRuleNode left but they are mostly
historical references so it makes sense to keep them.
Differential Revision: https://phabricator.services.mozilla.com/D5505
|
| |
|
|
|
|
|
| |
Bug: 1477628
Reviewed-by: heycam
|
|
|
|
|
|
| |
Bug: 1455784
Reviewed-by: Manishearth
MozReview-Commit-ID: AT4sud9goGV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I didn't bother not shifting there. We need to load the whole thing and shift
for at least one of cascade level / shadow cascade order.
Callers of level() other than for_rule_tree are non-existent in release builds,
so we'd be doing the shift anyway. I can implement the same thing for
shadow_cascade_order too, but I don't think that optimization is measurable in
any way, either, the compiler should make the decision.
And just in case, the simpler version actually generated less instructions in:
https://play.rust-lang.org/?gist=ceadb0d3cbce4eeca76e4d9ab9a1c744&version=nightly
with the simple thing.
Bug: 1455032
Reviewed-by: heycam
MozReview-Commit-ID: 8xPBJmlcyKh
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This was generated with:
./mach cargo fmt --package selectors &&
./mach cargo fmt --package servo_arc &&
./mach cargo fmt --package style
Using rustfmt 0.4.1-nightly (a4462d1 2018-03-26)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per https://drafts.csswg.org/css-cascade/#preshint and
https://html.spec.whatwg.org/multipage/#presentational-hints.
This was causing failures in the link color reftests with the preferences sheet
as a User sheet.
Bug: 1436782
Reviewed-by: bholley
MozReview-Commit-ID: 9iwEqPBw4CF
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Gecko, we handle XBL rules like author rules everywhere, except that
XBL rules are added and sorted in an independent step, behave as if it
has a separate level.
It is not clear to me why Stylo chose to add a separate level for XBL
rules, but it doesn't seem that there is anything special to do with
XBL rules.
This bug happens because we don't handle XBL important rules which are
handled as part of author rules in Gecko due to lack of the additional
level there. We should just follow what Gecko does here and handle them
all the same.
|
|
|
|
|
|
| |
Add an FFI to create a temporary ServoStyleContext with the animation value.
We need this because we calculate the Cumulative change hints to check
if we can ignore this animation segment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #18473.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|