Our webkit-gtk ebuilds have, -DUSE_WPE_RENDERER=$(usex wayland) # WPE renderer is used to implement # accelerated compositing under wayland I accidentally came across an entry in Michael Catanzaro's blog ($URL) that says, WebKitGTK’s CMake build system provides a USE_WPE_RENDERER build option, which is enabled by default. This option controls which graphics rendering stack is used: if enabled, rendering uses libwpe and wpebackend-fdo, whereas if disabled, rendering uses a legacy internal Wayland compositor. The option is provided because libwpe and wpebackend-fdo are newer dependencies that are expected to be unavailable on older (pre-2020) operating systems, so older operating systems legitimately need to be able to disable it. But this configuration receives little serious testing and the upstream developers do not notice when it breaks, so you really should not be using it unless you have to. This recently caused rendering bugs that appeared to be distribution-specific, which upstream developers were not willing to investigate because upstream developers could not reproduce the issue. Maybe its relationship to Wayland is historical, and we can enable the WPE renderer by default now on non-Wayland systems? If I remember, I'll test this myself during my next webkit upgrade.
WPE_RENDERER is only relevant for wayland, and enabling it requires enabling wayland: WEBKIT_OPTION_DEPEND(USE_WPE_RENDERER ENABLE_WAYLAND_TARGET)
Ok, thanks.
No worries. The WEBKIT_OPTION_DEPEND is why I put it like that under wayland and your bug did make me recheck that it's still this way in the latest release
I just saw this on GH from 4 days ago :( https://github.com/WebKit/WebKit/commit/cfe6c2f6af2a215de0e5eb574c4c03521b6cce6f
I think this just makes libwpe required when wayland target is enabled, which we already enforced in our ebuild. If that makes libwpe also required with USE=-wayland as well, then I'd consider that something I can talk with Michael about as a potential upstream bug
