Inter-client surface embedding

[Mark Thomas]

On Mon, 17 Feb 2014, Bill Spitzak wrote:

> Mark Thomas wrote:
>
>> I've pushed some doc updates to the protocol.xml file my git repo.  But
>> in terms of Jonas Ådahl's proposal, my protocol works the other way round:
>>
>>   A creates a main surface
>>   A creates a "hole" on that surface and sets its position and size
>>   A gets the uid (handle) from the server
>>   A passes that uid to B via IPC
>>   B creates a surface
>>   B creates a "plug" on that surface with the uid it got from A
>>   B receives a configure event from the server with the size of the hole
>>   B creates a buffer of the correct size and renders its image to the
>>     surface
>
> I do believe users are looking for something more like this than for 
> implementing a subcompositor. Subcompositor really worries me as it relies on 
> the buffers being passed through the intermediate client as fast as possible 
> (ie without copying), and information that clients use to figure out how to 
> allocate their buffers being passed the opposite direction. I can't believe 
> every client is going to get this right, and would seem to make it impossible 
> for a sub-client to take advantage of any new wayland api until the parent 
> client is updated.

Subcompositor worries me too, particularly for something like a panel, 
which does very little, really.  We have one compositor already so it 
seems strange for it to abdicate responsibility for compositing just 
because the parts of the image come from two different clients - surely 
the whole point of the compositor is to composite bits from different 
clients.

I understand there is the issue synchronization when interactively 
resizing, but even that isn't completely solved with a subcompositor, as 
what should it do if the nested client isn't responsive?

For my purposes I don't plan to resolve this.  I'm going to make a 
mate-panel-specific pair of interfaces that are used by mate-panel and 
libmatepanelapplet respectively, and not worry about the interactive 
resize issue because you can't interactively resize panels.

> I think the above description can be greatly simplified by removing the 
> "hole" and "plug" objects and just using a subsurface:
>
>  A creates a main surface
>  A creates a subsurface for the "hole"
>  A gets the uid of the subsurface from the compositor
>  A passes that uid to B via IPC
>  B uses this uid to get access to the subsurface
>  B can now attach buffers and do other actions to the subsurface

The "hole" and "plug" are meaningful objects and are needed, at least 
server-side, for some associated state.  They're also helpful for limiting 
the amount of uid-dipping a client can do, as only holes and plugs have 
uids.  Also you can't create a subsurface without both surfaces available, 
so there is a chicken-and-egg issue, too.

> I proposed this before but I think I am failing to communicate what I wanted. 
> The term "uid" seems pretty good and maybe makes it clearer. It's purpose is 
> so B can't just guess at objects and get access to them, and to be a simple 
> piece of data (probably a big number) that can be passed through IPC, in 
> particular as part of the argv sent to exec the child.

Having thought about it, I think I'm in agreement with Pekka and the 
others that a generic interface is probably not appropriate, as the 
requirements change depending on the use case.  What's probably more 
useful is making it easy for shell plugins to do it the way they want. 
So that's my plan.

> As far as I can tell Wayland will have no difficulties with two clients both 
> owning a subsurface and trying to update it, as it will serialize all the 
> requests and perform them in whatever order they appear. Either client can 
> destroy the surface and the other will cleanly hear about it.

I don't think that's true, at least for weston.  That may just be an 
implementation detail, though.

-- 
Mark.