[Webkit-unassigned] [Bug 115803] [GTK] Accelerated compositing does not work in Wayland

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=115803





--- Comment #13 from Iago Toral <itoral at igalia.com>  2014-01-24 06:21:23 PST ---
These patches provide an initial implementation to support Accelerated
Compositing under Wayland with WebKit2. This initial implementation
is mostly a prototype putting together the necessary pieces for this, but
further work is needed to make this ready for production environments.

The design is based on feedback from Wayland developers and it involves
having the UI Process implement a small nested Wayland compositor to
share a Wayland surface with the WebProcess. The implementation of the
nested compositor was based on the nested client from Weston.

These patches do not provide support for Accelerated Compositing under Wayland
with WebKit1.

Implementation details and known issues:

1. Patches apply clean on top of commit c69d3281e2f4dc6be7a42ce7ff3d8634a31f5313
from December 10, we need to rebase and test the patches against current webkit
and Wayland.

2. Since Wayland support requires EGL and there can be only one EGL target platform
configured (this is set at build time), in case that we build for both X11 and
Wayland at the same time we need to make sure that only the Wayland path goes
through EGL and have the X11 paths use GLX to create the GL context. If we are 
only building for X11, then we can have it go through the EGL path if that was
configured instead of GLX. This together with run-time detection of the
windowing system to select automatically between X11 and Wayland
paths -see point 7) below- makes code that creates the GL context a bit
complex at the moment because there are multiple options to consider.

3. Since Wayland requires EGL and GTK with Wayland support there are guards
for the Wayland code in the form #if USE(EGL) && PLATFORM(WAYLAND) && defined(GDK_WINDOWING_WAYLAND) most of the Wayland code paths. I think it would be best that PLATFORM(WAYLAND) is set only if we verify these 3 guards at configure time so we can reduce the guards to PLATFORM(WAYLAND) only or PLATFORM(WAYLAND) && PLATFORM(GTK) depending on the case. Also, as per 2), if we are trying to build for both Wayland and X11 but we lack GLX, then maybe we should disable one of the targets, we could disable either of them, but I guess Wayland would be the right one to drop for now.

4. If testing AC under Wayland with a build configured for both X11 and
Wayland targets, --disable-glx must be used, otherwise there is a bug somwehere
that makes GTK spit out-of-memory errors when trying to paint the widget with the results of the composition and nothing is painted on the WebView.

5. After visiting a page that enables the AC path, then leaving to another page, and then going back to the first page again using the browsers's back button shows rendering artifacts (composited layers are black). This is fixed if the page is reloaded though.

6. This is only a prototype and it only works with one WebView widget. Multiple
tabs or windows are not expected to work. For this to work we will need a way
to associate a widget with the wayland surface where we are doing the composition for that widget. This is more difficult in Wayland than in X11 because in Wayland with the nested compositor the shared Wayland surface is created in the WebProcess (LayerTreeHostGtk) where we have no context of the widget (which lives in the UI Process) and the nested compositor (which lives in the UIProcess) does not know for which widget it is creating the surfaces
requested from the WebProcess (since the wayland protocol does not include this
info). We might need to add a new message between the two processes to fix
this limitation or maybe there is something more creative we can do about this.
In any case, it needs some thinking.

7. Implementation is intended to support run-time detection of the windowing
system (wayland or x11) and select appropriate code paths depending on the case
by checking the type of the GdkDisplay. This needs more testing, but it seemed
to work well for me in the following scenarios at least:
  - Build only for X11 then run under X11
  - Build for X11 and Wayland, then run under Wayland (*)
  - Build for X11 and Wayland, then run under X11

(*) But this was not a complete test because as per 4) it required to
build with --disable-glx.

8. All tests were done against Weston running inside an X session, so
there is the possibility that this needs additional fixes to work in a pure
Wayland setup where there is no X server running. I have not tested this.

9. I only used MiniBrowser in my tests so it would be nice to see if 
this also works with Epiphany/Web as it is or if that would need more work.

10. This does not address the creation of the offscreen context for WebGL
under Wayland, Zan was working on that and I think his fix for that should
just work fine with my patches.

Future Work:

There are a number of FIXMEs in the code for things that need more work, but I
think  addressing 6) and 4) is the top priority. Testing on a pure Wayland
setup and also testing with Epiphany/Web are important too.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.