Inter-client surface embedding

[Pekka Paalanen]

On Tue, 18 Feb 2014 19:09:45 +0000 (GMT)
Mark Thomas <mark-wayland-devel at efaref.net> wrote:

> On Mon, 17 Feb 2014, Bill Spitzak wrote:
> 
> > 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.

Correct, but the replacement shell interface offered to the
mini-compositor's clients is nothing like a generic desktop shell
interface, but tailored precisely for the embedding use case at hand.

As for other interfaces, that is true, the mini-compositor needs to
implement everything its clients may want to use, but that should be
quite limited. If some generic Wayland core interface is too
complicated, you can simply not implement it, and have the needed
subset of the functionality in your own interfaces.

> 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.

"The whole point of the compositor is to composite bits from different
client." Deja vu. Indeed, is panel not exactly like a tiny compositor,
who takes the bits from panel applets and composites them to form the
panel as a whole?

Besides, it's not that much code, really. clients/nested.c is 1140
lines, and that includes support for EGL-passthrough so that
nested-client.c can efficiently use GLES rendering.

> 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?

If the mini-compositor's client is unresponsive, the mini-compositor
just does what any compositor would: keep showing the old content until
the client responds. The mini-compositor being an app itself can delay
reacting to the resize action it received. Avoiding drawing an
inconsistent window is trivial here.

> 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.

A wise decision. :-)


Thanks,
pq