Text editors laggy

[totaam]

Issue migrated from trac ticket # 2248

component: network | priority: major | resolution: fixed

2019-04-03 10:26:49: alyst created the issue

---

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.

[totaam]

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

[totaam]

2019-04-09 14:50:44: alyst uploaded file xpra_damage.log (39.7 KiB)

xpra 2.5 -d damage,compress log

[totaam]

2019-04-09 14:57:23: alyst commented

---

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.

[totaam]

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

[totaam]

2019-04-09 15:30:51: alyst commented

---

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.

[totaam]

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.

[totaam]

Updates:

• r22542 preparatory refactoring
• r22543 add minimum size for "scroll" encoding (defaults to 384 for now)
• r22544 bug fix (backported in 22545)
• r22546 use scroll encoding more aggressively

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:

• we could also be more clever about when to even attempt this delta
• let's switch to xxh3: xxh3 checksum #2285
• we could enable partial line detection: partial line scrolling #1429
• maybe remove the old delta buckets code: multi delta #756 - which is not supported by the html5 client, and of high complexity + limited beneffits

@alyst: does that work for you?

[totaam]

2019-05-09 19:15:37: alyst commented

---

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?

[totaam]

2019-05-09 19:16:39: alyst uploaded file 68.log (39.5 KiB)

xpra 22681 -d damage,compress log

[totaam]

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.

[totaam]

2019-05-10 12:05:51: alyst uploaded file xpra_info_20190510.log (196.3 KiB)

xpra info output r22699

[totaam]

2019-05-10 12:09:56: alyst uploaded file xpra_damage_scroll_20190510.log (88.8 KiB)

xpra 22699 -d damage,compress,scroll log

[totaam]

2019-05-10 12:12:03: alyst commented

---

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)

[totaam]

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.

[totaam]

2019-05-10 14:50:19: alyst commented

---

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

[totaam]

Yes, I've disabled opengl on the client in xpra.conf.

Please see 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?