Inter-client surface embedding

[Mark Thomas]

On Tue, 18 Feb 2014, Bill Spitzak wrote:

> On 02/18/2014 11:09 AM, Mark Thomas wrote:
>
>> 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.
>
> I proposed that the "uid" be an encrypted number so clients can't guess them 
> (or "dipping" as you call it). Basically if the server is asked for the 
> object for a given uid it fails if it is not a number recently delivered by 
> it to another client.

I've essentially done that, although the uid is more of a nonce.  Even a 
random number can be guessed or snooped.

> Otherwise you are going to have to create a "hole" and 
> "plug" object for every single Wayland object.

Only the ones you want to embed.  It's a rare occurrence.  Plus creating 
objects is easy because the wayland protocol is very lightweight.

>> Also you can't create a subsurface without both
>> surfaces available, so there is a chicken-and-egg issue, too.
>
> I don't understand this. Obviously when the subsurface is created there is 
> only one surface available (the parent) because the subsurface is not created 
> yet. That is why I have A create the subsurface. B is still in charge of the 
> buffers so there seems to be no problem here.

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.

>> 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.
>
> I don't like the idea that we are saying that things like Firefox have to be 
> shell plugins.

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.

It sounds like it could work, though I expect there would be lots of edge 
cases to work through.

Until someone actually tries it, though, this is all just hot air.


* - I had an idea for smooth, synchronized resizing and scrolling, where 
the outer client requests the inner client provide it a buffer with an 
extra amount of rendered data around the outside of the subwindow that it 
is providing.  The outer window crops this buffer to the correct 
dimensions (by asking the compositor to do so) and also draws the border 
of the subwindow and its scroll bars.  Then the outer client can scroll 
and resize synchronously by repainting the existing buffer it has with a 
differenct crop region, whilst asynchronously requesting a new buffer from 
the inner client with the new geometry.  I think this would work pretty 
well for the "document viewer" class of use case.  Just an idea, though. 
I don't plan to do anything with it.

-- 
Mark.