Introduce SerializedDisplayItem to reduce mem copies on DL construction

[kvark]

This PR addresses the part of #3358 about DL construction: instead of constructing the display items and associated data and passing through the serializer by value, we just pass the references around, which guarantees that no extra copies are made.

TODO:

• verify that the copies are gone (need the tool hosted/opened somewhere)
• Gecko try push with talos jobs

---

This change is 

[kvark]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=9783bb0b324e0a8f52fc0482dc9239449113eee0

[kvark]

With @jrmuizel help to set up the tool, it looks like the item copies are all gone for good 🎉 .
The old log starts with:

memcpy of 176 in _ZN13webrender_api12display_list18DisplayListBuilder9push_item17hc51010e3883501b0E @ 
  push_item webrender_api/src/display_list.rs:971
memcpy of 176 in _ZN13webrender_api12display_list18DisplayListBuilder9push_item17hc51010e3883501b0E @ 
  push_item webrender_api/src/display_list.rs:970
memcpy of 176 in _ZN13webrender_api12display_list18DisplayListBuilder31push_item_with_clip_scroll_info17ha854a06e3f76f0daE @ 
  push_item_with_clip_scroll_info webrender_api/src/display_list.rs:987
memcpy of 176 in _ZN13webrender_api12display_list18DisplayListBuilder19push_new_empty_item17hd4bea4fefd9abd2fE @ 
  push_new_empty_item webrender_api/src/display_list.rs:999
memcpy of 168 in _ZN13webrender_api12display_list18DisplayListBuilder15push_clear_rect17h117fa57bbf4055ffE @ 
  push_item webrender_api/src/display_list.rs:970
  push_clear_rect webrender_api/src/display_list.rs:1057
memcpy of 152 in _ZN13webrender_api12display_list18DisplayListBuilder9push_rect17h765bb472db42b8caE @ 
  push_item webrender_api/src/display_list.rs:970
  push_rect webrender_api/src/display_list.rs:1053
memcpy of 146 in _ZN13webrender_api12display_list18DisplayListBuilder9push_line17h7ecefb04d4b38bbfE @ 
  push_item webrender_api/src/display_list.rs:970

The new log doesn't have any of those:

memcpy of 144 in _ZN13webrender_api3api9RenderApi13report_memory17h8993ae29f9c6cd14E @ 
  new<std::sync::mpsc::oneshot::Packet<webrender_api::api::MemoryReport>> liballoc/sync.rs:292
  channel<webrender_api::api::MemoryReport> libstd/sync/mpsc/mod.rs:725
  msg_channel<webrender_api::api::MemoryReport> webrender_api/src/channel_mpsc.rs:62
  report_memory webrender_api/src/api.rs:1099
memcpy of 136 in _ZN13webrender_api3api9RenderApi13report_memory17h8993ae29f9c6cd14E @ 
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/shared.rs:245
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/mod.rs:1218
  recv<webrender_api::api::MemoryReport> webrender_api/src/channel_mpsc.rs:41
  report_memory webrender_api/src/api.rs:1101
memcpy of 136 in _ZN13webrender_api3api9RenderApi13report_memory17h8993ae29f9c6cd14E @ 
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/shared.rs:244
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/mod.rs:1218
  recv<webrender_api::api::MemoryReport> webrender_api/src/channel_mpsc.rs:41
  report_memory webrender_api/src/api.rs:1101
memcpy of 136 in _ZN13webrender_api3api9RenderApi13report_memory17h8993ae29f9c6cd14E @ 
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/stream.rs:224
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/mod.rs:1210
  recv<webrender_api::api::MemoryReport> webrender_api/src/channel_mpsc.rs:41
  report_memory webrender_api/src/api.rs:1101
memcpy of 136 in _ZN13webrender_api3api9RenderApi13report_memory17h8993ae29f9c6cd14E @ 
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/stream.rs:219
  recv<webrender_api::api::MemoryReport> libstd/sync/mpsc/mod.rs:1210
  recv<webrender_api::api::MemoryReport> webrender_api/src/channel_mpsc.rs:41

[kvark]

@jrmuizel r? this is ready, I believe, but you need to double check if this makes sense. The memcopies are gone, and Gecko try is green. I'm not seeing a significant difference in Talos, but maybe I'm looking at the wrong thing :)

[gw3583]

dl_mutate in g4 talos doesn't seem to have changed much, like you said [1].

But it seems like a worthwhile change to me, will wait to see what @jrmuizel thinks.

[1] https://treeherder.mozilla.org/perf.html#/graphs?series=try,1660472,1,1&selected=try,1660472,408314,654401468

[jrmuizel]

I think this is fine to take now. It moves the unwrap() back between SpecificDisplayItem construction and serialization which reduces our chances of inlining serialization and constant folding the SpecificDisplayItem into that code. However, because of rust-lang/rust#54878 we're not in a great position to achieve this right now.

@bors-servo r+

[bors-servo]

📌 Commit f72bf26 has been approved by jrmuizel

[bors-servo]

⌛ Testing commit f72bf26 with merge 323b7ea...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: jrmuizel
Pushing 323b7ea to master...