On Mon, Jul 8, 2013 at 8:05 AM, Iago Toral <[email protected]> wrote: > Hi, > > I am working on porting WebKitGTK+ to Wayland and we are having some > difficulties figuring out the proper way to deal with the multiprocess > architecture introduced with WebKit2. > > In WebKit2 we have two processes that are responsible for rendering the > contents of a webpage. The WebProcess takes care of parsing HTML, > identifying the various layers that are part of that HTML (that will be > rendered separately) and the composition of all these layers to create the > final view of the page. This composition stage is done with OpenGL. Once the > composition is done, the other process (UIProcess) needs a way to access the > results of the composition and paint them on the screen. > > In X11, this is achieved by having the WebProcess render the composition > results to an offscreen XWindow and sharing the XWindow ID between the two > processes. XComposite is used to redirect the XWindow to a pixmap. The > pixmap is painted in the UIProcess. > > As far as we know, there is no API in Wayland to allow two different > processes to share a surface, so we are not sure if the architecture I > describe above is currently supported in Wayland. > > So I guess my questions are: > - Is there a way to share a surface between two processes? > - If not, is there a way to implement this architecture in Wayland as it is > now? > - Would it be possible/interesting to add surface sharing API to Wayland so > that it supports this type of architectures naturally?
I proposed an extension[0] for solving this a while back, but since then as far as I know the general consensus has been to use nested compositing[1] for sharing surfaces between processes. The nested compositing is possible now, but if I remember correctly, it will require an extra draw, as there is no Wayland EGL API for directly providing buffers from a nested client to a surface of the host client. Regarding the mentioned extension, I had a hacked up proof-of-concept working, but have not continued working on it considering that it nested compositing and added EGL API is supposed to be the way forward. If I have understood the situation wrong, I'd be happy to continue with the previously proposed protocol extension. [0] http://lists.freedesktop.org/archives/wayland-devel/2013-March/008093.html [1] http://cgit.freedesktop.org/wayland/weston/tree/clients/nested.c Jonas > > We would really love to see WebKitGTK+ fully ported to Wayland and this is > probably the major obstacle we have at the moment so we are really looking > forward to seeing the options we have available to make this happen. > > Also, notice I am adding two colleagues of mine to the CC who are not > subscribed to this list. If you reply, please remember to keep them in the > loop. > > Iago _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
