> 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.
Yan Wang > > 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 > _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
