[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 #4 from Don Olmstead <don.olmstead at sony.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

If we want to split USE_LIBWPE that's fine. Just keep us in the loop and add whatever it is for the full USE(LIBWPE) into OptionsPlayStation.cmake.

>> Source/WebCore/PlatformGTK.cmake:43
>> +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.

Original reason for the USE(LIBPWE) was PLATFORM(WPE) = USE(GLIB) + USE(LIBWPE) and PLATFORM(PLAYSTATION) = USE(LIBWPE). I'm ok with coming up with a good way to split things but we'd probably have to audit the code to see what is what. For the PlayStation port our plan is to use LIBWPE fully as an abstraction over our own APIs to get code sharing. A simple USE_WPE_RENDERER and USE_WPE_INPUT would probably be ok. I know there was a Windows WPE port at some point but the repo hasn't seen much in the way of commits. For that you might have to split things more. I'd assume the Windows pasteboard code is what they'd want to use for example.

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

On the CMake side I've been debating making all libraries PRIVATE to better support the Apple internal builds. That would let you build each directory separately. Could also do ${target}_PRIVATE_LIBRARIES.

> Source/WebKit/Shared/CoordinatedGraphics/threadedcompositor/ThreadedCompositor.cpp:191
>      // FIXME: Enable this for WPE once it's possible to do these forced updates
>      // in a way that doesn't starve out the underlying graphics buffers.
> -#if PLATFORM(GTK)
> +#if PLATFORM(GTK) && !USE(WPE_RENDERER)

Can we address this FIXME? Fujii has a patch to turn on coordinated graphics on WinCairo and he modified this line as well.

If not wouldn't just !USE(WPE_RENDERER) be correct?

> Source/WebKit/SourcesGTK.txt:422
> +WebProcess/WebPage/libwpe/AcceleratedSurfaceLibWPE.cpp @no-unify

We've gotten non unified builds to work with WinCairo and Ross has been periodically doing that to make sure everything works. Perhaps that's something you all could spin up a bot for so we can figure out how to get rid of the @no-unify parts?

-- 
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/fb169eba/attachment.html>