Multiprocess rendering in wayland - webkitgtk+

[Iago Toral]

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?

Iago