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
