[webkit-gtk] Accelerated compositing support in wayland.

[zan at falconsigh.net]

Hi,

On Mon, Feb 8, 2016, at 05:48 PM, Emanuele Aina wrote:
> 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.
> 

This seems to currently be the only viable approach.

Cheers,
Zan

> 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
> 
> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk