Multiprocess rendering in wayland - webkitgtk+

[Daniel Stone]

Hi Yan,
Is this code available somewhere?

Cheers,
Daniel

On 9 July 2013 09:13,  <yan.wang at linux.intel.com> wrote:
> Hi,
>   I have implemented Wayland buffer sharing mechanism in WebKit2-efl based
> on nested client example. Nested client share buffer from one nested
> client to nesting client which is the Wayland server of nested client
> and Wayland client of Weston at the same time.
>   For WebKit2, there may be no only only one buffer which need be shared.
> So the basic idea is implementing a simple Wayland compositor/server (I
> called as Mini server.) like Weston on UI process Which could maintain a
> main loop to accept the link request from Web Process by another Wayland
> socket (E.g. wayland-10) because Weston use wayland-0 by default.
>   This simple Wayland server only need implement wl_compositor_interface
> and wl_surface_interface.
>   After web process creates a Wayalnd EGL window surface (Wayland hasn't
> Pixmap like X), we need call eglSwapBuffers twice. In the 1st swapping,
> surface_attach callback of wl_surface_interface will give you a
> wl_buffer pointer from graphics driver. You could use this wl_buffer to
> create EGL image / texture on UI process which includes the web content
> drawn by Web process. The 2nd swapping will swap your previous wl_buffer
> to back buffer of EGL window surface in graphics driver for drawing on
> Web process. Just ignore wl_buffer of 2nd swapping.
>   About keeping the pair of wl_buffer/EGL window surface, we could have
> several method. One is add a event into wl_surface_interface protocol.
> It si simple. Another method to use id of compositorCreateSurafce
> callback of wl_compositor_surface.
>   In general, the idea use wl_egl_window instead of X pixmap on Web
> process, and use EGL image/texture from wl_buffer to do compositing on
> UI process.
>   Hope the above idea useful for you.
>   Thanks.
>
> Yan Wang
>
>
>> 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
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel