Xpra: Ticket #2248: Text editors laggy

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.



Wed, 03 Apr 2019 11:51:10 GMT - Antoine Martin: owner changed; milestone set

@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.


Tue, 09 Apr 2019 13:50:43 GMT - Alexey Stukalov: attachment set

xpra 2.5 -d damage,compress log


Tue, 09 Apr 2019 13:57:23 GMT - Alexey Stukalov:

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.


Tue, 09 Apr 2019 13:58:00 GMT - Alexey Stukalov: version changed


Tue, 09 Apr 2019 14:05:13 GMT - Antoine Martin:

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?)


Tue, 09 Apr 2019 14:30:50 GMT - Alexey Stukalov:

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.


Tue, 09 Apr 2019 15:27:04 GMT - Antoine Martin: owner, status changed

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.


Thu, 25 Apr 2019 06:26:27 GMT - Antoine Martin: owner, status changed

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?


Thu, 09 May 2019 18:15:36 GMT - Alexey Stukalov:

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?


Thu, 09 May 2019 18:16:39 GMT - Alexey Stukalov: attachment set

xpra 22681 -d damage,compress log


Fri, 10 May 2019 03:34:46 GMT - Antoine Martin:

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.


Fri, 10 May 2019 11:05:50 GMT - Alexey Stukalov: attachment set

xpra info output r22699


Fri, 10 May 2019 11:09:55 GMT - Alexey Stukalov: attachment set

xpra 22699 -d damage,compress,scroll log


Fri, 10 May 2019 11:12:03 GMT - Alexey Stukalov:

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)


Fri, 10 May 2019 11:44:01 GMT - Antoine Martin:

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.


Fri, 10 May 2019 13:50:19 GMT - Alexey Stukalov:

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".


Fri, 10 May 2019 13:59:58 GMT - Antoine Martin: status changed; resolution set

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?


Sat, 23 Jan 2021 05:46:08 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2248