Multiprocess rendering in wayland - webkitgtk+

[yan.wang at linux.intel.com]

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
>