Multiprocess rendering in wayland - webkitgtk+

Wed Jul 10 19:31:01 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.

We use gerrit /platform/framework/web/webkit-efl.
I am not sure whether it is available for you?

Yan Wang

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