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.
Spec: http://dev.w3.org/csswg/css-device-adapt/
Currently, the actual viewport is used by the layout task as part of the reflow, and the compositor uses the zoom constraints. I'm not sure if anywhere else currently needs access to the constraints (i.e. there's no CSSOM as far as I can tell).
I did not implement sections 9 (viewport <META>) or 10 (handling 'auto' for 'zoom').
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/5361)
<!-- Reviewable:end -->
A rebuild after touching components/profile/mem.rs now takes 48 seconds (and
only rebuilds `profile` and `servo`) which is much lower than it used to be.
In comparison, a rebuild after touching components/profile_traits/mem.rs takes
294 seconds and rebuilds many more crates.
This change also removes some unnecessary crate dependencies in `net` and
`net_traits`.
* Simpler image cache API for clients to use.
* Significantly fewer threads.
* One thread for image cache task (multiplexes commands, decoder threads and async resource requests).
* 4 threads for decoder worker tasks.
* Removed ReflowEvent hacks in script and layout tasks.
* Image elements pass a Trusted<T> to image cache, which is used to dirty nodes via script task. Previous use of Untrusted addresses was unsafe.
* Image requests such as background-image on layout / paint threads trigger repaint only rather than full reflow.
* Add reflow batching for when multiple images load quickly.
* Reduces the number of paints loading wikipedia from ~95 to ~35.
* Reasonably simple to add proper prefetch support in a follow up PR.
* Async loaded images always construct Image fragments now, instead of generic.
* Image fragments support the image not being present.
* Simpler implementation of synchronous image loading for reftests.
* Removed image holder.
* image.onload support.
* image NaturalWidth and NaturalHeight support.
* Updated WPT expectations.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/5767)
<!-- Reviewable:end -->
