Hi Yan, thanks for the detailed reply, that was very helpful. It is also good to see that someone else has tried this before.
I'll definitely give this a go. Iago On lun, 2013-07-08 at 23:13 -0700, yan.w...@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 <ito...@igalia.com> wrote: > >> El 2013-07-08 08:38, Jonas Ådahl escribió: > >> > >>> On Mon, Jul 8, 2013 at 8:05 AM, Iago Toral <ito...@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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel