> On Mon, Jul 08, 2013 at 09:38:26AM +0200, Jonas Ådahl wrote: >> 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. > > It's actually almost identical to the sharing that WebKit2 does under > X - same amount of copies. The WebProcess will render into an > EGLSurface (just like under X where it renders to a EGLSurface for a > redirected window). On eglSwapBuffers(), the compositor is notified > that new contents is available and can bind the color buffer as a > texture, similar to how a a compositor is notified of damage for a > window under X. > > There's a few important things to notice in the nested example: > > - We establish a direct connection between WebProcess and UIProcess, > so it's even a little more efficient under Wayland since you don't > have to go through the X server to notify the UIProcess when the > content is changed. > > - We explicity avoid setting up a listen socket and pass the fd to > nested-client (WebProcess) by leaving it open across exec and > setting the WAYLAND_SOCKET environment variable to the fd number. > wl_display_connect() in the client will look for this and use that > fd when possible instead of trying to locate a listen socket.
Currently kalyan and I meet one issue that MiniBrowser UI responding speed is very slow when WebGL is rendered by 60FPS in normal window and 46FPS in full screen window (1280 x 1024). We haven't find the root cause. May 2 sockets (one is for Weston, another is for Mini server) will cause race? I am not sure. Yan Wang > > - We're using the same mechanism for buffer sharing that weston and > othere full compositors use (Wayland EGL and the > EGL_WL_bind_wayland_display extension). This way, we can reuse the > hw-enablement that we did to enable weston in the first place. > > - nested.c is a toytoolkit client, so it uses window.c and cairo-egl; > nested-client.c is a standalone EGL/GLES2 wayland client. > > - There's a lot of code in the example that is required to get it up > and run, but isn't directly related to the nested functionality; > all the toytoolkit code in nested.c and all the EGL/GLES2 > boilerplate in nested-client.c. In something like WebKit2, > > - There is some kind of issue in there that looks like nested only > runs at half the frame rate. I suspect we're waiting for the frame > events or sending them out too late or something - it's not that > the nested compositor model is inherently slow. > >> 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. > > Your extension made a lot sense in that it allowed an application to > forward buffers to the main compositor to let it do the final > compositing (and or color conversion) and save a copy. However, in > too many cases you want to also clip or scale or otherwise further > process the content. So I think it makes sense to first go with the > nested approach to let the client (UIProcess) use the buffer as a > texture and then later explore a way to create a subsurface and attach > the buffer as contents. > > Kristian > >> [0] >> http://lists.freedesktop.org/archives/wayland-devel/2013-March/008093.html >> [1] http://cgit.freedesktop.org/wayland/weston/tree/clients/nested.c >> >> Jonas >> >> > >> > We would really love to see WebKitGTK+ fully ported to Wayland and >> this is >> > probably the major obstacle we have at the moment so we are really >> looking >> > forward to seeing the options we have available to make this happen. >> > >> > Also, notice I am adding two colleagues of mine to the CC who are not >> > subscribed to this list. If you reply, please remember to keep them in >> the >> > loop. >> > >> > 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
