
A wayland compositor doesn't provide a mechanism for buffer sharing between clients. Under X, one client can render to a Pixmap and another can use it as a source in a subsequent drawing operations. Wayland doesn't have a mechanims to share Pixmaps or textures between clients like that, but it's possible for one client to act as a nested compositor to another client. This less work than it sounds, since the nested compositor won't have to provide input devices or even any kind of shell extension. The nested compositor and its client can be very tightly coupled and have very specific expectations of what the other process should provide. In this example, nested.c is a toytoolkit application that uses cairo-gl for rendering and forks and execs nested-client.c. As it execs the client, it passes it one end of a socketpair that will be the clients connection to the nested compositor. The nested compositor doesn't even create a listening socket. The client is a minimal GLES2 application, which just renders a spinning triangle in its frame callback.
…
…
Weston Weston is the reference implementation of a Wayland compositor, and a useful compositor in its own right. Weston has various backends that lets it run on Linux kernel modesetting and evdev input as well as under X11. Weston ships with a few example clients, from simple clients that demonstrate certain aspects of the protocol to more complete clients and a simplistic toolkit. There is also a quite capable terminal emulator (weston-terminal) and an toy/example desktop shell. Finally, weston also provides integration with the Xorg server and can pull X clients into the Wayland desktop and act as a X window manager. Refer to http://wayland.freedesktop.org/building.html for buiding weston and its dependencies.
Description
Languages
C
98.1%
Meson
1.3%
GLSL
0.3%
Shell
0.2%