Wayland rendering backend not working

[theCalcaholic]

Aknowledgements

• [X] I have checked that there's no other issue describing the same or similar problem that I currently have, regardless if it has been closed or open.

• [X] I can confirm that this is not an issue with the Discord website, but it is a problem specific to the WebCord itself.

• [ ] I have tried running the build from the master branch and it does not have any fixes implemented according to my issue.

• [ ] My issue describes one of the unstable and/or not fully implemented features.

• [X] I have found a workaround to mitigate or temporarily fix this issue (please write it in Additional context section).

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

19.0.6

Application version

v3.3.0

Bug description

Summary Electron has massive input lag for text fields under Wayland, at least if an Nvidia GPU is being used. Chrome's/Electron's new Ozone Wayland rendering backend can't be enabled

Details:

Electron works a lot better, when using the native Ozone Wayland rendering backend, which can be enabled with the flags --enable-features=UseOzonePlatform --ozone-platform=wayland.

I have successfully applied this workaround to a bunch of different Electron apps (e.g. Element, Visual Studio Code...), however, when trying to do the same for Webcord, the application crashes with a segfault:

$ /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=run.sh io.github.spacingbat3.webcord --enable-features=UseOzonePlatform --ozone-platform=wayland
[4:0625/154538.352902:ERROR:wayland_connection.cc(209)] Failed to connect to Wayland display
[4:0625/154538.352924:ERROR:ozone_platform_wayland.cc(226)] Failed to initialize Wayland platform
[4:0625/154538.352932:ERROR:env.cc(226)] The platform failed to initialize.  Exiting.
/app/bin/run.sh: line 16:     4 Segmentation fault      (core dumped) env TMPDIR=$XDG_CACHE_HOME zypak-wrapper /app/bin/webcord $FLAGS "$@"

Does this maybe require a compile flag to be enabled?

Additional context

My System:

OS: Fedora 36 GPU: Nvidia RTX 3080 graphics driver: proprietary nvidia driver, version 510 Desktop Environment: Gnome 42.2

[SpacingBat3]

I guess you're using Flatpaks – and why I can't blame you for that, you should know that WebCord's Flathub repository is entirely maintained by the community. See #116.

(...) which can be enabled with the flags --enable-features=UseOzonePlatform --ozone-platform=wayland.

Actually, --enable-features flag is redudant. Not only because ozone is used by the default now in Chromium engine even for X11, but also because WebCord does apply it automatically when it detects --ozone-platform=wayland as well as other tweaks that may help the users to have WebCord functional under native Wayland like client-side decoration (which is quite experimental in Electron and might still not be functional properly).

Electron has massive input lag for text fields under Wayland, at least if an Nvidia GPU is being used.

Have you tried turning on GPU optimizations in settings to test if that will help with at least few performance issues?

Chrome's/Electron's new Ozone Wayland rendering backend can't be enabled.

I'm not sure, but it could be because of Wayland not being passed to WebCord by Flatpak:

https://github.com/flathub/io.github.spacingbat3.webcord/blob/master/io.github.spacingbat3.webcord.yml#L9-L14

You should try to open the issue at WebCord's Flathub repository in that case.

[etrnal70]

Can confirm manually enabling wayland permission (using Flatseal) make it work. But for some reason it did not automatically use wayland platform (i already manually set XDG_SESSION_TYPE=wayland). So the --ozone-platform=wayland is still required to enable proper wayland support. I test this using xeyes

EDIT: Ah looks like the flags is actually required for proper wayland support, sorry

[TheEvilSkeleton]

But for some reason it did not automatically use wayland platform (i already manually set XDG_SESSION_TYPE=wayland). So the --ozone-platform=wayland is still required to enable proper wayland support.

That's due to Electron/Chromium. They're quite unstable on Wayland, so it's only optional.

[SpacingBat3]

That's due to Electron/Chromium. They're quite unstable on Wayland, so it's only optional.

In addition to this, I've tried to inject the --ozone-platform flag into the Chromium engine using the commandLine Electron API, but it didn't seem to work. I guess it is parsed even before Electron has executed the main script (most flags don't, which is why they're working fine). This is why this flag is a requirement for now.

[fontivan]

Using the rpm installation I get a different experience then reported above.

WebCord does launch using --ozone-platform and I can see that it is running native wayland and mostly works however there are some issues:

1. The left side of the application is corrupted
2. The title bar with the x button is missing
3. It does not fill the screen when maximized
4. Unable to open the file/edit/view/window/help menus

Blue squares were added to remove some personal information however you can see the difference between the two despite both being maximized.

I am using Fedora 36 and WebCord 3.5.0.

Native wayland:

XWayland:

[TheEvilSkeleton]

Can confirm on WebCord flatpak.

[TheEvilSkeleton]

Likely related to https://github.com/electron/electron/issues/34820.

[fontivan]

Using the rpm installation I get a different experience then reported above.

WebCord does launch using --ozone-platform and I can see that it is running native wayland and mostly works however there are some issues:

1. The left side of the application is corrupted

2. The title bar with the x button is missing

3. It does not fill the screen when maximized

4. Unable to open the file/edit/view/window/help menus

Blue squares were added to remove some personal information however you can see the difference between the two despite both being maximized.

I am using Fedora 36 and WebCord 3.5.0.

Native wayland:

XWayland:

I believe most of the issues I was seeing will be fixed in https://github.com/electron/electron/pull/34955

[SpacingBat3]

I believe most of the issues I was seeing will be fixed in electron/electron#34955

Great find! Althrough the original issue was because of Flatpaks, I may leave this open to track this pull request.

[xDShot]

Install flatpak version Install https://wiki.archlinux.org/title/Xdg-desktop-portal (probably already installed as dependency) Install one of portals Install flatseal, give permission to webcord for flatpak Profit

[SpacingBat3]

The PR has been recently merged into upstream and is present in Electron 20.0.2!

I guess I will close this issue and mark it as resolved. The issue will be resolved on the next release (since it will automatically bump Electron to the latest supported version).

[fontivan]

Using the rpm installation I get a different experience then reported above. WebCord does launch using --ozone-platform and I can see that it is running native wayland and mostly works however there are some issues:

1. The left side of the application is corrupted

2. The title bar with the x button is missing

3. It does not fill the screen when maximized

4. Unable to open the file/edit/view/window/help menus

Blue squares were added to remove some personal information however you can see the difference between the two despite both being maximized. I am using Fedora 36 and WebCord 3.5.0. Native wayland: XWayland:

I believe most of the issues I was seeing will be fixed in electron/electron#34955

All the issues I observed previously are fixed in 3.8.1; Wayland is working great for me now! In particular I am using the following launch options:

--ozone-platform=wayland --ozone-platform-hint=auto --enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer

[SpacingBat3]

--ozone-platform-hint=auto 
--enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer

@fontivan The last two shouldn't be required through, WebCord should apply these automatically.