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