[Bug] Frametime is getting worse when screen share is active

[Keqwerty]

Discord Account

keqwerty

Operating System

Arch Linux (6.6 LTS Kernel)

Linux Only ~ Desktop Environment

Gnome on Xorg

Package Type

Flatpak (also tried AUR)

What happens when the bug or crash occurs?

The bug happens when I play a game on Proton and start screen sharing. It doesn't matter if the window or the whole screen is captured, if the audio is on or not, and the quality of the screen sharing doesn't matter either. I don't know if this only happens on Proton games, as I don't have any other 3D games running natively on Linux.

Video: https://youtu.be/sCk4cPCa4gU

What is the expected behaviour?

I expected normal frametime when sharing the screen

How do you recreate this bug or crash?

1. Run some Proton game with mangohud to view frametime
2. Play without screenshare
3. Run screenshare
4. Compare frametime after and before screenshare

Debug Logs

APPIMAGE env is not defined, current application is not an AppImage
checkForUpdatesAndNotify called, downloadPromise is null
src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

src/gbm_drv_common.c:131: GBM-DRV error (get_bytes_per_component): Unknown or not supported format: 808530000

[2025-01-24 23:32:30.478] [venmic] [info] [patchbay] (handle) found default metadata: 39
[2025-01-24 23:32:30.478] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.usb-TEMPOTEC_TempoTec_HD_USB_AUDIO-01.analog-stereo"
[2025-01-24 23:32:30.478] [venmic] [info] [patchbay] (get) running venmic 6.1.0

Request Agreement

• I have searched the existing issues and found no similar issue
• I am using the latest Vesktop and Vencord versions
• This issue occurs on an official release (not just the AUR or Nix packages)

[ninja-]

there's no way you'll get hardware encoding on NVIDIA anyway, but with some tweaks you might get cpu encoding to be usable especially with a powerful cpu like that. does this happen if the gpu isn't starved running at 100% load?

[ninja-]

does this happen if you turn off the livestream preview? is your second screen running on a different refresh rate? do you want to test KDE instead to check if it's not a mutter bug?

[Keqwerty]

i'm already running vesktop only on CPU. I will try disable livestream preview and KDE Plasma as soon as i can.

[Keqwerty]

does this happen if you turn off the livestream preview? is your second screen running on a different refresh rate? do you want to test KDE instead to check if it's not a mutter bug?

I launched the game and screenshare with and without Hardware Acceleration on KDE Plasma (X11), the same problem.

[ninja-]

Check Wayland first

[Keqwerty]

Check Wayland first

Okay, but personally the option with Wayland doesn’t suit me, because I’m an Nvidia user.

[ninja-]

but knowing if it happens on Wayland is still a must have to diagnose this

[Keqwerty]

but knowing if it happens on Wayland is still a must have to diagnose this

I launched the game and screenshare on Wayland using a gamescope with SDL Backend X11 (otherwise the game would not start) and the frametime was smooth, looks like this is an X11 problem

[Keqwerty]

I also noticed that even after disabling the screenshare, the frametime will be worse until Vesktop is restarted.

[ninja-]

If it's X11 limitation there's nothing you can do about it.
You can try playing with NVFBC to record on X11 without this latency, but looks like even OBS plugin for NVFBC is dead, not sure if there is any maintained software supporting NVFBC

[LazyDope]

I am also experiencing a similar issue on KDE Wayland, however I've also noticed that if I'm watching someone else's stream then the issue doesn't occur, or at least isn't nearly as prevalent. I'm on the 6.12.11 kernel from Nobara 41, a fork of Fedora.

[negativems]

This happens to me. My temporary solution is screen share again and the FPS goes up.

You dont need stop the stream, just go to the screen share settings and click on "Go live" again and the stream will not change but the FPS will go up.

My specs:
OS: Arch
DE/WM: bspwm
GPU: RX 7800XT
CPU: Ryzen 7800X

[Keqwerty]

This happens to me. My temporary solution is screen share again and the FPS goes up.

You dont need stop the stream, just go to the screen share settings and click on "Go live" again and the stream will not change but the FPS will go up.

My specs: OS: Arch DE/WM: bspwm GPU: RX 7800XT CPU: Ryzen 7800X

unfortunately it didn't help me

[Keqwerty]

Is it possible to use the video capture method like in OBS or GPU Screen Recorder from DEC05EBA in future updates of Vesktop? I don't really understand development, maybe there are some technical reasons that don't allow this, so I'm just suggesting

[Vendicated]

screen capture is handled entirely by chromium and your system. we have 0 control over it. https://wiki.archlinux.org/title/Chromium#Hardware_video_acceleration

[LazyDope]

Do you know why watching someone else's stream might improve performance?

[Keqwerty]

Switched to wayland due new nvidia drivers update. Seems like all working correct.