Send display lists over IPC in multiprocess mode.
This patch set introduces the `--multiprocess` (`-M`) switch. Right now, all it does it cause display lists to be serialized, but eventually it will cause actual processes to be spawned.
r? @metajack
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6795)
<!-- Reviewable:end -->
`OptionalIpcSender<T>`.
`OptionalIpcSender<T>`dynamically switches between in-process and
out-of-process communication depending on whether multiprocess mode is
enabled.
The multiprocess command-line switch doesn't actually turn on
multiprocess mode yet, but it does control the behavior of
`OptionalIpcSender<T>`.
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
To actually make the multiprocess communication work, we'll need to
reroute the task creation to the pipeline or the compositor. But this
works as a first step.
profile: Make the time and memory profilers run over IPC.
Uses a couple of extra threads to work around the lack of cross-process
boxed trait objects.
r? @nnethercote
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6629)
<!-- Reviewable:end -->
Have BufferMap store NativeSurfaces and rename to SurfaceMap
We currently store LayerBuffers, because previously NativeSurfaces did
not record their own size. Now we can store NativeSurfaces directly,
which saves a bit of space in the surface cache and allows us to create
LayerBuffers only in the PaintTask.
This also means that instead of sending cached LayerBuffers, the
compositor can just send cached NativeSurfaces to the PaintTask.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6679)
<!-- Reviewable:end -->
The idea here is to land this before making images and canvas IPC-safe,
because this will shake out bugs relating to the shared memory. There
are currently test timeouts that are preventing multiprocess images and
canvas from landing, and I believe those are due to the inefficiency of
sending large amounts of data in the unoptimized builds we test with. By
moving to shared memory, this should drastically reduce the number of
copies and `serde` serialization.
Under the hood, this uses Mach OOL messages on Mac and temporary
memory-mapped files on Linux.
We currently store LayerBuffers, because previously NativeSurfaces did
not record their own size. Now we can store NativeSurfaces directly,
which saves a bit of space in the surface cache and allows us to create
LayerBuffers only in the PaintTask.
This also means that instead of sending cached LayerBuffers, the
compositor can just send cached NativeSurfaces to the PaintTask.
Add memory profiling for the compositor task
Currently only the BufferMap is recorded, but a later change will also
measure the memory usage of the compositor tree.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6640)
<!-- Reviewable:end -->
Implement HSTS (preload-only)
Implement HSTS (preload-only) servo/servo#6105
* Downloads the HSTS preload list from the chromium repo (same as gecko), then convert it to a list appropriate for servo.
* Reads the preload list when creating a resource task, and implements STS for those domains.
Still todo:
* Read Strict-Transport-Security headers from servers and add details to the in-memory HSTS list. (note: this requires hyper or servo to implement an STS header struct. Hyper seems like the appropriate location, so I will create an issue/PR there soon). The work for this is nearly done with the exception of adding a new ControlMsg and the new header.
* Persist HSTS list to disk with known hosts (perhaps a different issue should be raised for this?)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6490)
<!-- Reviewable:end -->
