Multiprocess rendering in wayland - webkitgtk+

Iago Toral itoral at igalia.com
Tue Jul 9 23:47:55 PDT 2013 

El 2013-07-10 03:21, yan.wang at linux.intel.com escribió:
>> 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.

I can only find these two webkit-efl repositories in tizen.org:

https://review.tizen.org/git/?p=framework/web/webkit-efl.git;a=summary
https://review.tizen.org/git/?p=profile/ivi/webkit-efl.git;a=summary

and they don't have a shared-surface branch.

how do I get to that webkit0-efl repository you mentioned?

Iago


> 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
>>

More information about the wayland-devel mailing list