Hi Yan, Is this code available somewhere? Cheers, Daniel
On 9 July 2013 09:13, <[email protected]> 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 <[email protected]> wrote: >>> El 2013-07-08 08:38, Jonas Ådahl escribió: >>> >>>> On Mon, Jul 8, 2013 at 8:05 AM, Iago Toral <[email protected]> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel >> > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
