RemoteDesktop: mutter sends old frames after input events
When using g-r-d, mutter will send old frames when input events happen.
This can be seen when currently no new frame is send (because nothing on the remote screen changes) and then right clicking somewhere to open a context menu.
Expected result: The context menu is shown on the client side.
Actual result: The context menu appears on the remote side (as expected), but not on the client side.
If this does not directly happen, close the context menu and try again (after the 2nd or 3rd try it should definitely happen).
In order to resolve the problem a frame update needs to be triggered. This can be for example moving the mouse on the client side over the position of the context menu (since the current entry will change the color upon hovering it).
Screencast of this issue with the VNC backend: VNC
Screencast of this issue with the RDP backend (https://gitlab.gnome.org/jadahl/gnome-remote-desktop/-/merge_requests/8): RDP
In beginning I thought this was just an issue with the RDP backend. Thats not the case, I tried resending any frames in the RDP backend when a frame updated completed (as long as there was one), used a mutex when sending a frame and processing updates (CheckFileDescriptor ()
) with the frame.
All that stuff didn't help and as soon as I was able reproduce the issue with the VNC backend, this couldn't be an issue in g-r-d.
In addition to that, try the following:
- Enable remote input for RDP (currently only possible via dconf (needs https://gitlab.gnome.org/jadahl/gnome-remote-desktop/-/merge_requests/8))
- Connect to the remote computer via RDP
- Watch some video via g-r-d where at lot of movement of the picture happens (music videos on Youtube are good candidates for this)
Observation: The video should be fluent.
Now move the cursor (e.g. in circles) over the screen from the client side while watching the video
Observation: The picture will jitter.
Now remove any grd_session_notify_pointer_button ()
, grd_session_notify_pointer_motion_absolute ()
, ... calls in g-r-d.
This will have the effect that input events are still processed in g-r-d, they just won't be transmitted to mutter.
Observation after compilation: The picture of the video won't jitter again upon moving the mouse cursor over it (since the input event is now effectively ignored).
Regarding the 'moving the mouse cursor over the video while watching'-part, I suggest you to use the RDP backend here (with RFX enabled (/rfx
for xfreerdp)), since it should be fluent most of the time.
Using the VNC backend (at least in my case) won't help here since the framerate with it is just too low to notice it (regardless of whether compression is being used).
The problem is not that the backends are/might be too slow, because when no frame update happened (first case with the context menu above), the next frame should be perfect (frame with context menu), and not being dropped since there is currently no other frame in process.
Using mutter/master, g-s/master here.