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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
