Inter-client surface embedding

[Bill Spitzak]

Mark Thomas wrote:

> I suggest you read up on the subsurface protocol.  A "subsurface" object 
> takes two "surface" arguments, one is the parent to attach to, and the 
> other is the child surface that becomes the subsurface.

You are right, the actual object I wanted to send from A to B is a 
surface, not a wl subsurface:

   A creates a surface
   A does calls so that surface is a subsurface
   A gets the id number for that surface and sends it to B using IPC
   B sends that number to wayland and gets the surface to attach buffers to.

> I think things like firefox are potentially better served by passing 
> through the buffers from the plugin, rather than the plugin connecting 
> to wayland itself -- a parent-child relationship rather than a sibling 
> one. That way it gets to do things to the buffer synchronously as it 
> passes through (like crop or scale it)*.  I think this is what is meant 
> by the "subcompositor" model.

This does sound like what is planned for wayland with the subcompositor 
idea. Firefox would act as a compositor, it's clients talk to it, and it 
then copies the buffers (hopefully in some zero-copy way) from the phony 
surfaces the clients are using to the actual surfaces that it sends to 
wayland.

It still bothers me that the subcompositor is not actually doing any 
compositing, and wayland is therefore aware of the full complexity of 
the scene, yet all this information must pass through the intermediate 
compositor.