I suspect it's quite common issue, but I had not found the corresponding ticket/wiki. It looks like certain apps always trigger a full-window update in Xpra (2.4.3), even if the actual area that is updated is small (I notice flickering video-encoding artifacts in the whole window). Unfortunately, it affects text editors and IDEs (e.g. Atom, RStudio, gedit). So text writing experience is severely degraded. Reducing window size helps, but that's not a perfect solution.
@alyst: 2.4.3 is no longer supported, the current version in the repository is 2.5 It includes numerous improvements related to this particular issue.
If you can reproduce the problem with this version, please post the server's -d damage,compress log output.
xpra 2.5 -d damage,compress log
I've tried xpra 2.5 (both client and server, Python2+GTK2 build (clipboard problems and missing window decorations with Python3+GTK3 on Wayland client)). My feeling is that the latency didn't improve much.
I've tried to start the server and run RStudio (https://aur.archlinux.org/packages/rstudio-desktop-preview-bin/) in maximized mode on 4K display, then type a few characters in the editing pane. Attached is the "-d damage,compress" output for this session. Looks like the damage is always the whole window area.
Looks like the damage is always the whole window area.
Exactly:
damage(0, 0, 3840, 2096, {}) wid=1
Which means that the application is repainting the whole 4K monitor all the time, even when you've changed just one character on screen.
There's only so much we can do when we have to deal with such a humongous amount of (totally unnecessary) pixels repaints every few hundreds of milliseconds or so.
That said, xpra is compressing those screen updates in around 50ms, and I would expect the client to decompress it very quickly, so your overall picture latency should be below 80ms (plus whatever network latency you may have) - which isn't too bad.
The only thing I can recommend at this point is to use an application that doesn't use this crazy window repaint behaviour.
Unless I am missing something, I would like to close this ticket as 'wontfix'.
BTW, there's also this:
using rgb as primary encoding, also available: h264, vp9, vp8, png, png/P, png/L, webp, rgb24, rgb32, jpeg, mpeg1, mpeg2
You usually want to leave this on auto unless you're on a low-latency Gbps connection or better.
It's usually best to play with [min-]quality and [min-]speed rather than the encoding.
That said, lz4 is compressing down to less than 5% of the original size, which is great already. (perhaps a mostly empty window?)
Unless I am missing something, I would like to close this ticket as 'wontfix'.
The problem is that it concerns most modern IDEs. RStudio is QtWebEngine?-based. Atom & VSCode are Electron-based (I've just checked damage pattern for Atom: it does per-line redraws of the editor window for each typed character). Even with lower resolutions the latency is quite disturbing. I wonder if xpra can adjust the final damage area by actually comparing the pixels since the last update.
Replying to Alexey Stukalov:
I wonder if xpra can adjust the final damage area by actually comparing the pixels since the last update.
We do this for scrolling detection, but only when we get enough screen redraws per second. Doing this for every screen update could be costly. Let me think about this.
Updates:
This enables "scroll" encoding, which does compare with the previous image on a line by line basis only - so the blinking cursor of rstudio only costs this now:
compress: 0.1ms for 1200x16 pixels at 0,868 for wid=3 using rgb24 with ratio 3.5% ( 75KB to 2KB), sequence 15, client_options={'rgb_format': 'BGRX', 'lz4': 1}
And the rest of the bogus damage request is ignored.
This does come at a cost:
may_use_scrolling(XShmImageWrapper(BGRX: 0, 0, 1200, 900), {}) supports_scrolling=True, has_pixels=<built-in method has_pixels of xpra.x11.bindings.ximage.XShmImageWrapper object at 0x7ff09f90d800>, content_type=text, non-video encodings=['png', 'png/P', 'png/L', 'webp', 'rgb24', 'rgb32', 'jpeg']
best scroll guess took 1ms, matches 98% of 900 lines: 0
1ms for 1200x900 may not seem like much, but the overhead will be higher (as a percentage) for lower resolutions, hence why we have a minimum size since r22543. And this is generally not needed as most applications don't have this buggy damage behaviour.
Notes:
@alyst: does that work for you?
That sounds amazing, thanks a lot! Sorry for not replying earlier. I've tested it some days ago and today I've checked again with the latest revision (r22681). Unfortunately, it looks like it doesn't work for me. I've attached the log of rstudio cursor blinking (starts with the small window, then maximized to 4K, the a little bit shrinken). It looks like it is still doing full window updates. Am I doing something wrong?
xpra 22681 -d damage,compress log
Please include the "scroll" debug flag (-d damage,compress,scroll) and xpra info output.
r22686 adds debug logging to all the code paths that skip using the scrolling detection.
xpra info output r22699
xpra 22699 -d damage,compress,scroll log
Please include the "scroll" debug flag (-d damage,compress,scroll) and xpra info output.
Did it (with r22699). Looks like the scrolling detection is disabled for some reason (no scrolling: not supported)
no scrolling: not supported
My best guess is that opengl accelerated rendering is disabled. You have not attached the client output to this ticket, so I can't be sure why that is. This would explain the extra slowness too.
My best guess is that opengl accelerated rendering is disabled.
Ah, so scrolling is disabled if there's no opengl. Yes, I've disabled opengl on the client in xpra.conf. I have Intel HD 620, and these full 4K window redraws seemed to be better handled with opengl disabled.
Now I've enabled opengl on the client, and rstudio and atom are definitely more responsive when typing (newlines still cause hiccups, but I guess that's fine).
Thanks a lot for your support! Pls let me know if you need any additional info to tune the "scrolling detection".
Yes, I've disabled opengl on the client in xpra.conf.
Please see wiki/ReportingBugs, following the instructions there would have captured this information from the get go.
Now I've enabled opengl on the client, ..
"scrolling" is now also enabled for the non-opengl case: #2295
So you can compare scrolling with both options.
newlines still cause hiccups, but I guess that's fine
What hiccups?
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2248