Avoid undefined behaviour by allocating with align 1.
The allocation APIs require that the alignment is a power-of-two;
meaning 1 is the "I don't care" alignment, not 0.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6852)
<!-- Reviewable:end -->
Implement Msg::Status with serialized url upon mouseover
Credits for Mike Blumenkrantz (@zmike), I just rebased against trunk and
fixed the url serialization.
Fixes#6178.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6181)
<!-- Reviewable:end -->
Update to the latest skia
Now GLRasteizationContexts require having an active GLContext. This will
allow preserving GLContexts and possibly framebuffers between
rasterization sessions, improving GL Rasterization performance.
Linux Before:
+ Painting Per Tile 4.5559 4.3392 1.6920 18.5548 74
Painting 170.1554 151.8353 0.0008 350.1093 28
Linux After:
+ Painting Per Tile 3.8726 3.1299 1.5848 12.6732 62
Painting 13.5480 10.8947 0.0029 39.1198 23
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6842)
<!-- Reviewable:end -->
Now GLRasteizationContexts require having an active GLContext. This will
allow preserving GLContexts and possibly framebuffers between
rasterization sessions, improving GL Rasterization performance.
Linux Before:
+ Painting Per Tile 4.5559 4.3392 1.6920 18.5548 74
Painting 170.1554 151.8353 0.0008 350.1093 28
Linux After:
+ Painting Per Tile 3.8726 3.1299 1.5848 12.6732 62
Painting 13.5480 10.8947 0.0029 39.1198 23
Implement ChildNode::before & ChildNode::after
Continued from #6536
The current implementations of `ChildNode::before` and
`ChildNode::after` do not match the WHATWG spec. This commit updates the
implementations to match the spec.
Our current implementation of `ChildNode::after` passes all the WPT
tests. So I made sure to add a regression test that failed with the
current implementation. There are a few other unit tests I added
to exhaust other corner cases I encountered.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6800)
<!-- Reviewable:end -->
script: Squash duplicate animation tick events in the queue.
This prevents them from piling up endlessly if the JS
`requestAnimationFrame()` callback takes a long time to complete.
r? @jdm
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6841)
<!-- Reviewable:end -->
Document libglu1-mesa-dev dependency.
Missing this caused
src/gpu/gl/unix/SkNativeGLContext_unix.cpp:10:20:
fatal error: GL/glu.h: No such file or directory
on my new laptop.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6831)
<!-- Reviewable:end -->
Add a `kind` field to memory reports.
This is used for two memory reporting improvements.
- It's used to distinguish "explicit" memory reports from others. This
mirrors the same categorization that is used in Firefox, and gives a single
tree that's the best place to look. It replaces the "pages" tree which
was always intended to be a temporary stand-in for "explicit".
- It's used to computed "heap-unclassified" values for both the jemalloc
and system heaps, both of which are placed into the "explicit" tree.
Example output:
```
| 114.99 MiB -- explicit
| 52.34 MiB -- jemalloc-heap-unclassified
| 46.14 MiB -- system-heap-unclassified
| 14.95 MiB -- url(file:///home/njn/moz/servo2/../servo-static-suite/wikipe
dia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyc
lopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.49 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
| 1.36 MiB -- layout-worker-3-local-context
| 1.34 MiB -- layout-worker-0-local-context
| 1.24 MiB -- layout-worker-1-local-context
| 1.24 MiB -- layout-worker-4-local-context
| 1.16 MiB -- layout-worker-2-local-context
| 0.89 MiB -- layout-worker-5-local-context
| 0.38 MiB -- layout-task
| 0.31 MiB -- display-list
| 0.07 MiB -- local-context
| 1.56 MiB -- compositor-task
| 0.78 MiB -- surface-map
| 0.78 MiB -- layer-tree
```
The heap-unclassified values dominate the "explicit" tree because reporter
coverage is still quite poor.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6802)
<!-- Reviewable:end -->
Implement getComputedStyle
It's not quite done but can probably be reviewed anyway.
I still need to finish up a few of the ToCss impls, I just got lazy and wanted to make sure things worked.
The computation of the used values is definitely not right, I'm going to investigate that.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6798)
<!-- Reviewable:end -->
This is used for two memory reporting improvements.
- It's used to distinguish "explicit" memory reports from others. This
mirrors the same categorization that is used in Firefox, and gives a single
tree that's the best place to look. It replaces the "pages" tree which
was always intended to be a temporary stand-in for "explicit".
- It's used to computed "heap-unclassified" values for both the jemalloc
and system heaps, both of which are placed into the "explicit" tree.
Example output:
```
| 114.99 MiB -- explicit
| 52.34 MiB -- jemalloc-heap-unclassified
| 46.14 MiB -- system-heap-unclassified
| 14.95 MiB -- url(file:///home/njn/moz/servo2/../servo-static-suite/wikipe
dia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyc
lopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.49 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
| 1.36 MiB -- layout-worker-3-local-context
| 1.34 MiB -- layout-worker-0-local-context
| 1.24 MiB -- layout-worker-1-local-context
| 1.24 MiB -- layout-worker-4-local-context
| 1.16 MiB -- layout-worker-2-local-context
| 0.89 MiB -- layout-worker-5-local-context
| 0.38 MiB -- layout-task
| 0.31 MiB -- display-list
| 0.07 MiB -- local-context
| 1.56 MiB -- compositor-task
| 0.78 MiB -- surface-map
| 0.78 MiB -- layer-tree
```
The heap-unclassified values dominate the "explicit" tree because reporter
coverage is still quite poor.
Dispose layout data for every node removed from the tree
Fix for #6754.
cc @jdm – I believe this is all that's required for the fix, but until I get a better sense of #6813, I'm unsure of the best way to test this.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6815)
<!-- Reviewable:end -->