El 2013-07-10 03:21, yan.w...@linux.intel.com 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.
how do I get to that webkit0-efl repository you mentioned?
Iago
Yan Wang
Cheers,
Daniel
On 9 July 2013 09:13, <yan.w...@linux.intel.com> 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 <ito...@igalia.com>
wrote:
El 2013-07-08 08:38, Jonas Ådahl escribió:
On Mon, Jul 8, 2013 at 8:05 AM, Iago Toral <ito...@igalia.com>
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
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
