Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharing windows on non active desktop lagging #45

Closed
maricn opened this issue Jan 25, 2021 · 10 comments
Closed

Sharing windows on non active desktop lagging #45

maricn opened this issue Jan 25, 2021 · 10 comments
Labels
enhancement New feature or request

Comments

@maricn
Copy link

maricn commented Jan 25, 2021

I'm using Arch Linux with Wayland (swaywm) on Thinkpad X1C gen7.

When I share a window to my Android phone (Sony XZ2c) Brave browser, it works well.. As long as the window is being rendered on the laptop.

When the window shared is not being rendered on the visible workspace on the source machine, the updates are very laggy. For example, if I try playing a video on my laptop and share it to my phone and navigate away from the workspace hosting the video on the laptop, the video sharing is only sending a frame every second or so.

@maricn maricn added the enhancement New feature or request label Jan 25, 2021
@pavlobu
Copy link
Owner

pavlobu commented Jan 25, 2021

Hey @maricn, your problem is very specific, it may be a limitation of the current version of chromium engine of electron. Deskreen is built with electron. So maybe in never releases, when we will be updating electron, this problem will be gone.

Cheers,
Paul

@maricn
Copy link
Author

maricn commented Jan 26, 2021

I'd rather guess it's related to the way wayland specifies rendering of clients to happen, although I'm a real noob with DE/WM internals.

Also, what would help from a very noobish blackbox diagnosis perspective - if deskreen would be based on a build of electron that has RTC_USE_PIPEWIRE=true flag (per https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility#electron) then we could try casting whole desktops/workspaces/screens.

For instance, I can already successfully cast my second virtual desktop through google meet conference, and that seems like a good workaround in case swaywm's (wayland's) clients wouldn't continually render when they're outside of the viewport.

Just for the sake of reference - this issue seems related just on OSX #57

I hope I didn't mumble a bunch of nonsense there 😬 it's really not my field

@pavlobu
Copy link
Owner

pavlobu commented Jan 26, 2021

@maricn can you check if this example works smooth on latest chromium browser in your wayland environment?
https://www.webrtc-experiment.com/Pluginfree-Screen-Sharing/#8420463382421998

if it does work, then it can be easily fixed with updating electron to latest version and making a new release to fix issues for folks using wayland

Cheers,
Paul

@maricn
Copy link
Author

maricn commented Jan 26, 2021

@maricn can you check if this example works smooth on latest chromium browser in your wayland environment?
webrtc-experiment.com/Pluginfree-Screen-Sharing/#8420463382421998

Just checked it - yes it works.

Also, thanks for quick responses and good luck with the project! <3

@pavlobu
Copy link
Owner

pavlobu commented Jan 26, 2021

Hi,
Ok SO it is good news for you! :)

our current version of electron we are using in Deskreen is:
"electron": "^10.1.5",
that is using chromium version:
"85.0.4183.121"

The latest version of electron is:
11.2.1
that is using Chromium 87.0.4280.141

so versions differ a lot!

the last thing I want to ask you, what is the chromium version you were testing WebRTC screen sharing on your Wayland environment and you said it worked well? (the full version like above)

Cheers,
Paul

@maricn
Copy link
Author

maricn commented Jan 27, 2021

Cool. Looking forward to reviving some old devices :)

I'm on Chromium Version 88.0.4324.96 (Official Build) Arch Linux (64-bit), but I'm not exactly sure from which version of Chromium the full screen share started working properly.

@pavlobu
Copy link
Owner

pavlobu commented Jan 27, 2021

hi, I made new release with updated chromium engine version for electron.
https://github.com/pavlobu/deskreen/releases/tag/v1.0.2
if it does fix your problem, pls share here.

Cheers,
Paul

@maricn
Copy link
Author

maricn commented Jan 27, 2021

🔥 💣 💥 worked like a charm!! :)

@maricn maricn closed this as completed Jan 27, 2021
@NullSense
Copy link

NullSense commented Mar 19, 2021

Hi, I am unable to get this working with the appropriate flags, as deskreen just crashes (without the flags, when sharing my screen,it's just black).
Here's a dump:

~ via 🐍 v3.9.2 on ☁️  took 6s
❯ XDG_SESSION_TYPE=wayland RTC_USE_PIPEWIRE=true ./Deskreen-1.0.11.AppImage --enable-features=WebRTCPipeWireCapturer --enable-features=UseOzonePlatform --ozone-platform=wayland
13:09:14.094 › /tmp/.mount_DeskrejrP1yx/resources/app.asar/main.prod.js : Deskreen signaling server is online at port 3131
13:09:14.454 › Checking for update
(node:8211) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
13:09:15.112 › Update for version 1.0.11 is not available (latest version: 1.0.11, downgrade is disallowed).
13:09:15.112 › checkForUpdatesAndNotify called, downloadPromise is null
(node:8211) electron: The default of contextIsolation is deprecated and will be changing from false to true in a future release of Electron.  See https://github.com/electron/electron/issues/23506 for more information
zsh: segmentation fault (core dumped)  XDG_SESSION_TYPE=wayland RTC_USE_PIPEWIRE=true ./Deskreen-1.0.11.AppImage

Software versions:

pipewire: 1:0.3.24-1
pipewire-pulse: 1:0.3.24-1
xdg-desktop-portal-wlr: 0.2.0-1
xdg-desktop-portal:1.8.0-1
(AUR) electron12-bin: 12.0.0.beta.30-1

Running on Arch kernel 5.11.7-arch1-1. Screen sharing on chromium works.

@jmou
Copy link

jmou commented Apr 11, 2021

Maybe try without the ozone flags? Those crash for me, but just this works:

./Deskreen-1.0.11.AppImage --enable-features=WebRTCPipeWireCapturer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants