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