On Tue, 18 Feb 2014 19:09:45 +0000 (GMT) Mark Thomas <mark-wayland-de...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
