Vencord / Vesktop

Vesktop is a custom Discord App aiming to give you better performance and improve linux support
GNU General Public License v3.0
4.33k stars 193 forks source link

Hovering over window makes X11 screensharing drop frames #545

Open MJnHerAbsolution opened 6 months ago

MJnHerAbsolution commented 6 months ago

Describe the bug

Screensharing a window (without audio, to be clear, otherwise the quality/framerate drops as described by other issues) is stable at whatever setting it's set to, up until my cursor moves over it, at which point it drops to something in the realm of 3-6 fps. Does not matter if the window's in focus.

Disabling compositing does solve this issue, but that comes with the side effect of freezing my primary monitor (165hz VRR so probably why,) which renders it non-viable for me. This doesn't seem to occur on Wayland at all, only dropping frames when audio's involved.

I am on Kubuntu 23.10 with KDE Plasma 5 (whichever version ships with the distro,) and an AMD CPU & GPU. This does not occur when sharing a screen.

To Reproduce

Steps to reproduce the behavior:

  1. Get in a call with an alt account. Doesn't matter if it's on phone or if you're running a separate Vencord client.
  2. Screenshare a window--or Firefox, at least
  3. Join screenshare on your other account. Note that it looks fine without a cursor, even if the image is moving (say, a YouTube video,) but the second you move it across, it tanks.

Expected behavior

I would expect to achieve the same framerate/quality as I do when sharing a screen, or when my cursor isn't over it.

Screenshots

(I do have to go soon and didn't think to get any--if needed, I can provide when I'm off work)

Desktop (please complete the following information):

Command line output


> vesktop@1.5.1 start /home/lucibelle/Desktop/Vesktop
> pnpm build && electron .

> vesktop@1.5.1 build /home/lucibelle/Desktop/Vesktop
> tsx scripts/build/build.mts

[arRPC > ipc] not available, trying again (attempt 1)
[arRPC > ipc] listening at /run/user/1000/discord-ipc-1
[arRPC > websocket] 6463 in use!
[arRPC > websocket] listening on 6464
[arRPC > process] started
[2024-04-25 14:55:43.497] [venmic] [info] [patchbay] (get) running venmic 3.4.2
[2024-04-25 14:55:43.501] [venmic] [info] [patchbay] (handle) found default metadata: 35
[2024-04-25 14:55:43.501] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.pci-0000_13_00.6.analog-stereo"
Nuggeh commented 6 months ago

Experienced a similar bug to this is happening on Wayland too. Stream is perfectly fine until the cursor is moved in the window being streamed, then the stream starts to jitter and stutter until the cursor goes still again. Not sure it's exclusive to X11 or Plasma 5.

nauldagarotada commented 6 months ago

Experiencing the same issue under plasma 6 wayland. It looks like it's happening on xwayland programs. Streaming is normal on wayland apps. Managed to capture it on video and used extramaus to illustrate that it's indeed when running xwayland applications. It looks like it does not matter if I'm sharing a screen or a single application. (vesktop compiled from source at d294128)

https://github.com/Vencord/Vesktop/assets/168395248/7ceb9ca4-e407-4a4b-a2d4-8e54ce919559

https://github.com/Vencord/Vesktop/assets/168395248/4f04375c-d827-4be3-bea4-906c9e58da34

PhantomShift commented 6 months ago

Experiencing the same issue under plasma 6 wayland.

I believe this is caused by a bug unrelated to the original report. Kwin 6.0.3 seems to have a regression that broke WebRTC screenshares in particular, whereas apps like OBS and Spectacle are working just fine. Downgrading to 6.0.2 fixes this issue for me. https://bugs.kde.org/show_bug.cgi?id=486081

kerriganx commented 6 months ago

There is a bug in WebRTC capture: https://issues.chromium.org/issues/333945842 https://issues.webrtc.org/issues/338232699

I can confirm that provided patch (https://webrtc-review.googlesource.com/c/src/+/350042) fixes issue for me. I have sucess applying the patch for Chromium, I did test web version of Vencord, and it is working without original issue. But having problems to make it work with Electron (to fix issue in Vesktop). Firstly, I have to install fresh archlinux in virtual machine and downgrade all packages to specific date April 22 (the same date when official electron29 package was built), otherwise it fails to build. Then I copy resulting electron29 package to live system and install it. I use vesktop-git package from aur and build it with _electron_version=29. I believe it uses system electron, but when I start stream I don't see any difference, the issue doesn't go away. If someone uses Arch I wouldn't mind if someone help.

PolisanTheEasyNick commented 6 months ago

I think that the best way will be just to wait for Chromium to completely test patch and merge it into new version of Chromium and wait for electron to use this patched Chromium version because manually patching and building Chromium is very complicated for most users.

kerriganx commented 6 months ago

Yes, I think so too. Until the problem is resolved upstream, for those who don't want to wait, they can use one of the following workarounds: 1) Downgrade kwin to 6.0.2 or 2) If you have multiple displays, you can set up capture in OBS, then right click on the preview window and choose "Full-screen Projector". Move projector window to display you NOT streaming. Open Vesktop, start stream and capture that projector window. So that way you basically don't have cursor on streaming display (but have it on projector) because projector window is on another display, and therefore not affecting by issue.

IlChitarrista commented 2 months ago

Could anyone test if this is fixed by https://github.com/Vencord/Vesktop/pull/828 as per https://github.com/Vencord/Vesktop/pull/828#issuecomment-2317124540?

PhilVoel commented 1 month ago

Possibly fixed by 37db07807a62435b99a6a11037c84184517ebc69 if somebody wants to test with a build from current master