[webkit-gtk] Accelerated compositing support in wayland.

[Emanuele Aina]

ChangSeok Oh wrote:

> I wonder how the AC support in wayland environment is going. As I 
> remember, some discussion happened during last hackfest. So what is
> the decided approach to bring the AC into wayland world?
> Is there anyone working on it? If so, could you share remaining work
> ro to-do list?
> If necessary, I'd like to help to make the feature go forward.

Yay!

During the hackfest we discussed some general goals[1] which I can try
to recap here but I recommend reading the original discussion too.

Compositing in the WebProcess has several drawbacks, the most glaring
in this context is that it only works under X11 since it relies on
blitting to a UIProcess X window from the WebProcess.

This led us to two problems: how to efficiently share textures from the
WebProcess to the UIProcess and how to composite the results in
UIProcess.

The most suitable solution for the second problem is likely using a Gtk
GLArea[2] widget inside the WebView, which would give us a GL canvas
which is perfectly integrated with the application paint loop (working
widget stacking and other niceties).

Discussing the first problem with gfx people resulted in acknowledging
the fact that due to a multitude of reasons using the Wayland protocol
is the only way we're more or less guaranteed that there's an efficient
way to share surfaces and import them as GL textures in the UIProcess.

This means that the idea is to have the UIProcess run as a simplified
Wayland compositor, with the WebProcesses being the Wayland clients.
We then need two sockets: the one for the WebKit protocol and one for
the Wayland protocol.

Only a subset of the Wayland protocol is needed (eg. we can ignore
input as it is managed through the WebKit protocol). We probably may
need to add a custom Wayland extension to provide synchronization
points where we make sure the state shared over the two sockets is
consistent. Another option would be to use a Wayland protocol extension
to encapsulate the whole WebKit protocol so only one socket would be
needed, but I guess the other option is easier to implement.

Using Wayland between the WebProcess and UIProcess is merely an
implementation detail to efficiently share surfaces across the process
boundary: the idea is to behave the same under X11, being a "nested"
compositor in the same way as Weston which can run under X11 or Wayland just fine.

A future idea could even be to forward surfaces to the real Wayland
compositor: we could then have full hardware accelerated zero-copy
video playback. Unfortunately, for this to work properly we need to
wait for the GTK+ Scene Graph Kit (GSK) to land, or we'd break widget
stacking: in some special scenarios it may be acceptable, but since we
can't do that as a general purpose widget we could add an option to
enable such behavior. This is really just an optimization, so we can
ignore it for the moment.

I have no specific details about the implementation, but I hope the
high-level pieces are clear. :D

[1] WebKit2GTK+ and compositing in the UIProcess:
    https://lists.webkit.org/pipermail/webkit-gtk/2015-December/002465.html
[2] GtkGLArea: https://developer.gnome.org/gtk3/stable/GtkGLArea.html
[3] GTK+ Scene Graph Kit:
    https://www.bassi.io/articles/2014/07/29/guadec-2014-gsk/
[4] PoC GTK+ Wayland compositor:
    https://github.com/alexlarsson/wakefield


-- 
Emanuele Aina
www.collabora.com