xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Last modified 10 hours ago

#2248 new defect

Text editors laggy

Reported by: Alexey Stukalov Owned by: @…
Priority: major Milestone: 3.0
Component: network Version: 2.5.x
Keywords: Cc:

Description

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.

Attachments (1)

xpra_damage.log (39.7 KB) - added by Alexey Stukalov 2 weeks ago.
xpra 2.5 -d damage,compress log

Download all attachments as: .zip

Change History (8)

comment:1 Changed 3 weeks ago by Antoine Martin

Milestone: 3.0
Owner: changed from Antoine Martin to Alexey Stukalov

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

Changed 2 weeks ago by Alexey Stukalov

Attachment: xpra_damage.log added

xpra 2.5 -d damage,compress log

comment:2 Changed 2 weeks ago by 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.

comment:3 Changed 2 weeks ago by Alexey Stukalov

Version: 2.4.x2.5.x

comment:4 Changed 2 weeks ago by 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?)

comment:5 Changed 2 weeks ago by 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.

comment:6 in reply to:  5 Changed 2 weeks ago by Antoine Martin

Owner: changed from Alexey Stukalov to Antoine Martin
Status: newassigned

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.

comment:7 Changed 12 hours ago by Antoine Martin

Owner: changed from Antoine Martin to @…
Status: assignednew

Updates:

  • r22542 preparatory refactoring
  • r22543 add minimum size for "scroll" encoding (defaults to 384 for now)
  • r22544 bug fix (backported in r22545)
  • 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: #2285
  • we could enable partial line detection: #1429
  • maybe remove the old delta buckets code: #756 - which is not supported by the html5 client, and of high complexity + limited beneffits

@alyst: does that work for you?

Last edited 10 hours ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.