Update to latest rust-layers
The compositing context, painting context and display metadata have all
been collapsed into a single NativeDisplay class.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6525)
<!-- Reviewable:end -->
Getting these down to the embedding API level required that I redo the bindings generator again, so this is more commits than anticipated.
@mbrubeck @Manishearth @pcwalton but NOT @larsbergstrom so don't even look at this.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6219)
<!-- Reviewable:end -->
This fixes various race conditions that affect test execution when using the servodriver product. It doesn't yet do enough to make servodriver a viable alternative to the normal servo test executor.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6161)
<!-- Reviewable:end -->
* Wait for the correct pipeline to return a LoadComplete message
before signalling a load is complete, and ensure that the root
pipeline is the one corresponding to the active document of the top
level browsing context, even if this has not yet painted.
* Ensure that TakeScreenshot operates on the correct pipeline
* Reset the screenshot ready flag whenever we decide that we are ready
to take a screenshot.
This is important for the SERVO_HEADLESS configuration, because
creating a clipboard on linux creates an X context which then causes
reftest instability.
Example output from the memory profiler:
```
| 1.04 MiB -- url(http://en.wikipedia.org/wiki/Main_Page)
| 0.26 MiB -- display-list
| 0.78 MiB -- paint-task # new output line
| 0.78 MiB -- buffer-map # new output line
```
The buffer maps aren't huge, but they're worth measuring, and it's good
to get the memory profiler plumbing into PaintTask.
I've done a bit of job to get this done. Right now readback is still used, but we have a `LayerId` -> `CanvasRenderer` map on the paint task, that we can use to get rid of that.
I'd want review, to see if this is a good approach (I know it's not the initial `CanvasId` -> renderer approach, but it's pretty similar, since a canvas involves a `PaintLayer`).
I had to do a bit of refactoring to avoid cyclic dependencies between canvas and gfx. I'd want you to review them too.
It's mergeable and doesn't break any tests :P
Some of my main concerns:
* Does the canvas render really need to be behind an `Arc<Mutex<T>>`?
* I can't clone a `NativeSurface` right now (that's why the `SendNativeSurface()` msg is unimplemented in the WebGL task). It should be easy to add that to rust-layers, supposing the caller is responsible to mark it as non-leaking, any reason to not do it?
cc @jdm @pcwalton
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6083)
<!-- Reviewable:end -->
The basic idea is it's safe to output an image for reftest by testing:
- That the compositor doesn't have any animations active.
- That the compositor is not waiting on any outstanding paint messages to arrive.
- That the script tasks are "idle" and therefore won't cause reflow.
- This currently means page loaded, onload fired, reftest-wait not active, first reflow triggered.
- It could easily be expanded to handle pending timers etc.
- That the "epoch" that the layout tasks have last laid out after script went idle, is reflected by the compositor in all visible layers for that pipeline.
