Multiprocess rendering in wayland - webkitgtk+

[Jonas Ådahl]

On Mon, Jul 8, 2013 at 8:05 AM, Iago Toral <itoral at igalia.com> 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