Multiprocess rendering in wayland - webkitgtk+
jadahl at gmail.com
Mon Jul 8 00:38:26 PDT 2013
On Mon, Jul 8, 2013 at 8:05 AM, Iago Toral <itoral at igalia.com> wrote:
> 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
> - 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 for solving this a while back, but since
then as far as I know the general consensus has been to use nested
compositing 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.
> 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
More information about the wayland-devel