Laggy mouse when screen sharing on 4K resolution #66
Comments
|
Screen sharing disables hw cursors. swaywm/wlroots#2091 may help wrt. Sway CPU usage. |
|
I see, I guess making the operations asynchronous will help also with the input lag issue. I wonder in what stage that ticket and the associated MR is, but I will ask in there. Just for the record, GNOME's Wayland compositor (Mutter, I think) doesn't have this issue. I guess somebody could take a look at how this problem is solved over there, maybe the same solution applies here as well.
I'll keep this questions open for a couple of days, incase some further insight comes with regards to the input lag issue. |
|
Maybe GNOME never disables hw cursors when screensharing, but I don't think it should make that big of a difference... |
|
I have the same issue and while I don't understand much about the technology behind it I've made some observations that may be note worthy:
I don't really care much about sharing my screen at full 4K resolution, by the way, it only worsens the compression when the video goes through the network. Maybe there is any way to do down scaling early to improve performance? |
wf-recorder may default to export-dmabuf these days. Or ratelimit the screen capture. Not sure. We request frames as fast as the compositor can give them (after we copy them for pipewire). Could be a performance bottleneck. It would be a good idea to add some debugging output regarding framerate.
You could always change your output geometry first. That's probably the best option for performance. We're trying to do minimal video processing in xdpw (all we do now is y_invert the frames as they come in upside down) |
No, wf-recorder can only pump out shm frames from the compositor. |
|
Sorry for insisting on this subject, but I still don't get it: what is causing the mouse lag? If there is no significant CPU nor GPU usage, then what is it? Is there a way for me to do debugging (maybe active some debug logs), or some kind of profiling to figure it out? Also, if it's related to the disabling of the hardware mouse cursor, is there any way of working around it? Also, what is the reason for it? Is it that otherwise the cursor wouldn't appear on the recording? |
|
My only guess would be that calling screencopy with a software cursor and no rate limiting is slowing down the rendering loop, but I honestly have no idea. I don't have any 4k displays and I can't reproduce at 1920x1080. You could try adding an artificial delay between frames. I'm pretty sure wayvnc does this if you are looking for an example. You can enable debug (or even trace) logging if you like. You need to start xdpw manually as described in the FAQ and the help text will tell you what options you have. Trace logs do print on every single frame, but we don't include timing information, so you' have to do something clever to determine a frame rate. You could also add some code to calculate a running frame rate. Again, something similar is done in wayvnc. |
|
@danshick You are probably right on this one: I just tried wayvnc, and the mouse lag is almost non-existing (maybe it's not even there at all and I'm just imagining it). I checked out the source code also, and the delay seems to be implemented in a pretty straightforward way. I will give it a try. |
Let me know how it goes. We'd happily accept a PR to rate limit the frames if it helps. |
The goal is to rate-control the capturing, as it can represent a performance issue; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to rate-control the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant.
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
|
I had the same problem with input from a wacom pen. Drawing whilst screen sharing on 4K led to lag and jerky lines. zsolt-donca's implementation seems to solve the issue for me. |
|
Thanks for the feedback. As soon as one of us has time to review that PR, it will be considered for merging. |
|
Adding some more information – my screen is not quite 4k, but has higher resolution than 2k. I found that when just one webrtc capturing session is active (via pipewire/wlr portal) then the slowdown is not very noticeable, but gets worse as more capture sessions are started. My very naive guess, without looking at the code, would be that the frame buffers are being re-acquired anew for each stream/session/whatever they are called, thus slowing down sway. It that is indeed the case, I imagine that this could be mitigated to an extent by copying buffers inside the portal for each session? |
|
Ah, that's a lot of pixels for CPU copies. swaywm/wlroots#2091 should help the compositor. |
Actually, in xdpw, as long as you are streaming the exact same output with the exact same settings (at the moment, this just means pixel format and cursor on or off, until output selection is implemented) we only push the contents of the buffer to pipewire once. Each new session that is started shares the exact same pipewire node, so there is no additional copying on our side with each additional session. That said, what the downstream apps do with those buffers is likely to add latency regarding how quickly pipewire can recycle those buffers. I wouldn't expect this to cause noticeable jitter in your compositor though. That's surprising. Thanks for the info. |
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of the capturing, as it can represent a performance issue and can cause a laggy mouse; see emersion#66. The delay for the current frame is based on the time it took to capture the previous frame. The targeted frame rate is a constant. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of capture while in screencast, as it can represent a performance issue and can cause input lag and the feeling of having a laggy mouse. This commit addresses the issue reported in emersion#66. The code measures the time elapsed to make a single screen capture, and calculates how much to wait for the next capture to achieve the targeted frame rate. To delay the capturing of the next frame, the code introduces timers into the event loop based on the event loop in https://github.com/emersion/mako Added a command-line argument and an entry in the config file as well for the max FPS. The default value is 0, meaning no rate control. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
The goal is to control the rate of capture while in screencast, as it can represent a performance issue and can cause input lag and the feeling of having a laggy mouse. This commit addresses the issue reported in #66. The code measures the time elapsed to make a single screen capture, and calculates how much to wait for the next capture to achieve the targeted frame rate. To delay the capturing of the next frame, the code introduces timers into the event loop based on the event loop in https://github.com/emersion/mako Added a command-line argument and an entry in the config file as well for the max FPS. The default value is 0, meaning no rate control. Added code to measure the average FPS every 5 seconds and print it with DEBUG level.
|
To anybody affected by this issue: #74 was merged that allows you to control the rate with which the frames are captured, reducing the load on the compositor and thus mitigating this issue. It is not a proper solution, as you sacrifice the ability to faithfully capture your screen. To apply the rate control, you either need to manually start [screencast]
output_name=
max_fps=10 |
|
Thanks @zsolt-donca for your great work! I'll close this issue as this is the best solution we could ask for until #9 is resolved. |
When starting screen sharing from a browser with WebRTC, the mouse cursor gains a significant lag on the display that is being shared. My other screen doesn't seem to be affected, the mouse cursor works just fine over there, even while the screen sharing is being active. Stopping the screen sharing makes the lag disappear.
I am using two 4K displays. This is probably related to the 4K resolution, as if I switch the resolution of one of the displays to 1920x1080 and share that display, the mouse cursor is moving perfectly smooth.
This lag also feels when typing on the keyboard, so I think it's a general input lag problem, and not just specific to the mouse.
I made a screenshot of htop with the screen sharing being active on the other screen. It It shows
sway,firefox,xdg-desktop-portal-wlrbeing the biggest CPU users:For comparison, the mouse is not laggy when on GNOME in Wayland mode (tested with a Fedora 33 live image), nor in Xorg mode. I wouldn't mind the relatively high CPU usage if there wasn't this input lag.
Another related question: why can I share only one of my displays? When the browser prompts, there is only a single display being available. It happens to be my "main" display, so actually it's fine for me, I'm just curious.
I also mentioned this in #65 .
The text was updated successfully, but these errors were encountered: