[RFC, alpha] Capturing infrastructure

[kvark]

As we start re-focusing on the correctness issues, it becomes vital to be able to capture a bug and replay it in a reduced standalone environment. Unfortunately, the current binary/player infrastructure does not provide a solid way to achieve that, see #2231.

Changes to existing logic:

• internal representation of Document on the WR backend side is changed to have a new DocumentView item.
• BuiltDisplayList/DisplayItemRef serialization (used for JSON/RON) is rewritten to use stronger typing (with CompletelySpecificDisplayItem enum) and consistent/robust code. Result also looks a bit better now, since items have less nesting.
• WR API got "debug-serialization" feature, and WR itself got "capture" feature

New API calls:

• save_capture(path)
• load_capture(path) - still not sure if we might instead just always create a new WR backend instead of trying to overwrite the current state with a capture (comments are welcome!)
• In the examples, we can now hit 'C' to save a capture or load one, if it's already at "captures/example".

Here is what a capture looks like on disk:

This is just the start. What will follow is a series of issues/PRs to extend the function in the following ways:

1. full external/blob image serialization (this is the biggest piece missing to call this a "beta"). Currently, the following paths are incomplete:
   • #2236: tiled blobs
   • #2237: external GL textures
2. #2234: storing images as PNG
3. #2235: supporting other serial formats for the scenes, like JSON, with configurable pretty-printing
4. wrench integration, removal of the existing JSON/RON writers
5. #2238, #2239: more exciting stuff ;)

---

This change is 

[glennw]

Reviewed 20 of 20 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions.

---

webrender_api/Cargo.toml, line 11 at r1 (raw file):

nightly = ["euclid/unstable", "serde/unstable"]
ipc = ["ipc-channel"]
serial = []

I'm not sure about the naming of this - perhaps we can either come up with something a bit more descriptive or add a comment explaining what this feature provides?

---

webrender_api/src/display_item.rs, line 58 at r1 (raw file):

#[derive(Clone, Copy, Debug, Deserialize, PartialEq, Serialize)]
pub struct GenericDisplayItem<T> {
    pub item: T,

Do we need @gankro or @jrmuizel to check that this won't have any bad side effects on serde codegen for (de)serialization times?

---

Comments from Reviewable

[glennw]

A couple of very minor comments, otherwise this looks great to me.

[kvark]

@glennw thanks for the review!
I've implemented a bit of missing critical logic for blobs and external buffers, renamed the wr-api feature to "debug-serialization", and confirmed with Jeff about the GenericDisplayItem changes being harmless.

[glennw]

@kvark r=me if you want to get this merged now then, or we can revisit if there are still more commits to come first.

[kvark]

@glennw thank you!
I believe this is a fairly complete PR that is ready to merge. But I don't want to rush it in (and now would be a perfect moment to do so, given how everyone is still getting relaxed after All Hands). Let's have a few more interested parties taking a look and then proceed.
r? @jrmuizel or @gankro

[jrmuizel]

I've only skimmed it but it seems fine to me.

[kvark]

@jrmuizel please take a look at the last commit with an extra raw test, as requested. Afterwards, it should be ready to sail.

[jrmuizel]

Looks good to me.

[kvark]

Alright-y, thanks everyone who looked at the code!
@bors-servo r=glennw,jrmuizel

[bors-servo]

📌 Commit 1088d90 has been approved by glennw,jrmuizel

[bors-servo]

⌛ Testing commit 1088d90 with merge afaa8bb...

[bors-servo]

☀️ Test successful - status-appveyor, status-travis
Approved by: glennw,jrmuizel
Pushing afaa8bb to master...