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