Multiprocess rendering in wayland - webkitgtk+

Tue Jul 9 19:21:45 PDT 2013

> Hi Yan,
> Is this code available somewhere?

If you could get the code of webkit0-efl from tizen.org, you could find
them on shared-surface branch. Kalyan integrated my implementation into
it.
Thanks.

Yan Wang

>
> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>