[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 #6 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Don Olmstead from comment #4)
> Comment on attachment 370036 [details]
> 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.

I have no idea what that is for, so I'll do whatever yous guys tell me to do.

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

Yes, it's on top of my TODO when this patch lands, I have to see how many tests fail because of this. Unfortunately it's not easy to fix, because libwpe and fdo backend expect the frame cycle to be always the same and they contains asserts to ensure it.

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

Yes.

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

I don't remember why I added that, I'll check if it's still needed and why.

-- 
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/3f489a68/attachment-0001.html>