[Webkit-unassigned] [Bug 197944] [GTK] Use WPEBackend-fdo for accelerating compositing in Wayland instead of the nested compositor

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #3)
> Comment on attachment 370036 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=370036&action=review
> 
> Cool.
> 
> No complaints about the code itself, but I think we need to discuss the
> preprocessor guards used here.
> 
> P.S. I'll keep an eye on the Fedora  packaging of libwpe. We'll need to
> discuss with Berto who will package libwpe for Debian.
> 
> > Source/WebCore/PlatformGTK.cmake:43
> > +if (USE_WPE_RENDERER)
> > +    list(APPEND WebCore_INCLUDE_DIRECTORIES
> > +        "${WEBCORE_DIR}/platform/graphics/libwpe"
> > +    )
> > +endif ()
> 
> Hm, so this is like USE(LIBWPE), except more limited, we are only using the
> renderer component of libwpe?

Yes.

> I guess lots of things break if we turn on USE(LIBWPE)?

Note that we use libwpe only for accelerated compositing implementation under wayland. We can't use libwpe in X11 or for non-ac mode. And in any case we really want to use GDK for everything else in all configurations.

> We need to think carefully about the guards we use here, because this has
> the potential to become a confusing mess. I don't think we should be using
> libwpe while having USE(LIBWPE) turned off. The whole point of USE(LIBWPE)
> was to allow using libwpe without being the WPE port. So we should use that.
> Except we can't, because that's too much libwpe for GTK. Am I correct?

Right, we don't want to use the pasteboard or input apis from libwpe, we want GDK.

> We might need to introduce some WPE features concept, so PlayStation and GTK
> can both use separate bits of libwpe (USE_WPE_EVENTS, USE_WPE_RENDERER,
> USE_WPE_PASTEBOARD, USE_WPE_WHATEVER), while WPE port can use the whole
> thing. If we do that, then your USE_WPE_RENDERER option could live on, while
> USE_LIBWPE would either go away or could be set if any libwpe suboption is
> enabled.

I never liked USE(LIBWPE) to be honest (even less the classes named FooLibWPE), but I agree that PLATFORM(WPE) and USE(WPE) would be even more confusing. In any case, if we want to split USE(LIBWPE) I would do it in a previous patch to this, or in a follow up.

> > Source/WebCore/platform/graphics/PlatformDisplay.cpp:45
> > -#if USE(LIBWPE)
> > +#if USE(WPE_RENDERER)
> 
> See, this needs further discussion with Don.

What exactly?

> > Source/WebKit/PlatformGTK.cmake:479
> > +if (USE_WPE_RENDERER)
> > +    list(APPEND WebKit_LIBRARIES
> > +        PRIVATE
> 
> Oops! (PRIVATE doesn't work here.)

What doesn't work? What should I do then, just remove it?

> > Source/WebKit/UIProcess/glib/WebProcessPoolGLib.cpp:119
> > +        wpe_loader_init("libWPEBackend-fdo-1.0.so");
> 
> This looks frighteningly fragile. What happens when there's a soname bump?
> Does wpe_loader_init() crash (which would be OK), or is there a fallback
> (less good then a crash: users might not realize it's broken), or does
> everything just fail to work?

If there's a soname bump there will be two .so, so the old should exist. We depend on 1.0, so it should always exists. The same way we depend on gtk3.

> > Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:29
> > +#if PLATFORM(WAYLAND) && USE(EGL) && !USE(WPE_RENDERER)
> 
> How long will we keep WaylandCompositor around as a fallback path?

At least until we have tested the new path enough and all distros are shipping libwpe. Hopefully we can remove it after branching for 2.26, but I guess we will keep it for one more cycle.

> It's only needed for accelerated rendering, right? So we don't really need
> to keep it. We could fallback to software rendering if libwpe is unavailable.

No, let's give people and distros time to switch to libwpe before removing a feature like accelerated compositing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190517/f734388e/attachment.html>