> El 2013-07-10 03:21, [email protected] escribió: >>> 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. > > I can only find these two webkit-efl repositories in tizen.org: > > https://review.tizen.org/git/?p=framework/web/webkit-efl.git;a=summary > https://review.tizen.org/git/?p=profile/ivi/webkit-efl.git;a=summary > > and they don't have a shared-surface branch.
We use gerrit /platform/framework/web/webkit-efl. I am not sure whether it is available for you? Yan Wang > > how do I get to that webkit0-efl repository you mentioned? > > Iago > > >> 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
