Adds a second renderer implementation to the nested compositor example
that creates a subsurface for each of the client's surfaces. The
client buffers are directly attached to the subsurface using the
EGL_WL_create_wayland_buffer_from_image extension instead of blitting
them in the redraw_handler.
The new renderer is always used if the parent compositor supports the
wl_subcompositor protocol and the EGL extension is available.
Otherwise it will fall back to the blit renderer.
Eventually the nested compositor example will want to be able to cope
with either rendering as it does now with a blit to an intermediate
surface or by attaching the client buffers directly to a subsurface
without copying. This patch moves the code that is specific to the
blitting mechanism into a separate set of functions with a vtable to
make it easier to add the second way of rendering in a later patch.
Previously the frame callback list was tracked as part of the global
compositor state. This patch moves the list to be part of the surface
state like it is in Weston. The frame callback now iterates the list
of surfaces to flush all of the callbacks. This change will be useful
when the example is converted to use subsurfaces so that it can have a
separate frame callback for the subsurface and flush the list for an
individual client surface rather than flushing globally.
The nested compositor example now responds to damage requests and
tracks them in the pending buffer state. This isn't currently used for
anything and it is immediately discarded when the surface is commited
but it will be used later when the example is converted to use
subsurfaces.
The buffer and frame callback state on the surfaces in the nested
compositor example are now double-buffered so that they only take
effect when the commit request is received. This doesn't really make
much difference for the current state that the example has but it will
be useful when more state is added in later patches.
This copies the buffer reference busy count implementation from Weston
to the nested compositor example and adds an internal nested_buffer
struct that we could eventually use to attach data. This will be
useful to adapt the example to use subsurfaces so that we can attach
our compositor-side buffer to the resource.
Otherwise if the surface is destroyed then it will crash when it later
tries to render all of the surfaces. You can replicate this by doing
killall weston-nested-client while the example is running.
Calls into cairo-gles may change the current context, so it was only by
chance that sometimes we had the proper one as current and updated the
correct texture in surface_attach().
In order to fix this, calling display_acquire_window_surface() before
binding the texture for setup is necessary. However this call has the
side effect of allocating a cairo surface for the window. At flush time,
the existence of this surface will cause an eglSwapBuffers(), even
if no rendering was done to it, leading to undefined contents on the
screen. This happens when the idle redraw task runs while there is a
pending frame callback.
Workaround this by moving the texture setup from surface_attach() to the
redraw handler, so that the cairo surface is only allocated when
redering is done.
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.
