[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 #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 370036
  --> https://bugs.webkit.org/attachment.cgi?id=370036
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?

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

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?

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.

> Source/WebCore/platform/graphics/PlatformDisplay.cpp:45
> -#if USE(LIBWPE)
> +#if USE(WPE_RENDERER)

See, this needs further discussion with Don.

> Source/WebKit/PlatformGTK.cmake:479
> +if (USE_WPE_RENDERER)
> +    list(APPEND WebKit_LIBRARIES
> +        PRIVATE

Oops! (PRIVATE doesn't work here.)

> 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?

> 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?

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.

-- 
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/20190516/68f1511a/attachment-0001.html>