We currently serilaize the displaylist into a byte buffer and send it through IPDL.

This is problematice because:

• Sometimes the displaylist is large and we fail to make that large contiguous allocation. We don't actually need the serialized content to be in a content to be in a single buffer, it is only a byproduct of the current implementation.
• IPDL copies the potentially large serialized DL multiple times (buffer -> shmem -> buffer) which is expensive and eats away precious memory bandwidth.

I propose that we instead:

• Have a pool of relatively large shmems of a fixed size.
• When we serialize the displaylist, we write the bytes directly into the current shmem of the displaylist builder
• Once the shmem is full we grab another one from the pool and continue serializing into it (allocate a new one if need be).
• When we send the displaylist, we now have to send an array of handles to the shmems instead of a byte buffer.
• On the webrender side we deserialize directly off this list of shmems. I don't thing it would be an issue for serde to read form a Reader that is internally broken up into several buffers but I haven't looked closely.
• In order to manage the lifetime of these shmems we store an atomic reference count in the shmems themselves. Once we are done deserializing we decrement the reference count and let go of the references to these shmems.
• In the pool on the client side we can walk through all allocated shmems and check if the reference count is back to zero before reusing the shmem on the content side.

Since the displaylist could potentially be built in the same process as webrender (unless WR really only ever runs in the GPU process), we can abstract away the backing buffer to chose between shmem and regular memory allocation (the same way we do for Shmem/MemoryTextureClient/Host).