Multiprocess rendering in wayland - webkitgtk+

[Jonas Ådahl]

On Mon, Jul 8, 2013 at 3:40 PM, Iago Toral <itoral at igalia.com> wrote:
> El 2013-07-08 08:38, Jonas Ådahl escribió:
>
>> 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
>
>
> Thanks Jonas, that is useful, I will look into it. The need for an extra
> draw is suboptimal though, do I understand correctly that this extra Wayland
> EGL API you mention is intended to fix this?

Yes, at least that is my understanding of it. I don't think I've seen
any patches for it though, except this[0] which has some similarities.

Jonas

[0] http://lists.freedesktop.org/archives/wayland-devel/2013-March/007746.html

>
> Iago