xpra icon
Bug tracker and wiki

Opened 3 weeks ago

Last modified 11 hours ago

#2056 assigned enhancement

large delta buffer for applications updating slowly

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 3.1
Component: encodings Version: 2.4.x
Keywords: Cc:

Description

See ticket:2049#comment:4.

The only way we can deal with those pathological repaints from badly written applications would be to double-buffer the whole window picture and try delta compression on it.
A quick pass using lz4 will tell us if delta compression is worth doing. (if the repaint is bogus, lz4 compression will achieve ~90% compression or more effortlessly)

To reduce the cost (memory bandwidth mostly, some CPU), this could be limited to:

  • windows without video
  • windows with less than N frames per second
  • windows below a certain size?
  • high quality / low speed?

Maybe merge this with the scroll detection code? (saves having the full copy in memory - but prevents delta..)

Change History (6)

comment:1 Changed 3 weeks ago by Antoine Martin

Milestone: 2.53.1
Status: newassigned

comment:2 Changed 15 hours ago by Nathan Hallquist

My users want a terminal window that has a little less latency. I've done some more testing of both gnome-terminal and xterm and I've got some questions (this is very much outside my expertise so please forgive and correct me if these questions are dumb):

  1. The flicker between lossy and RAW can be unpleasant with terminal-like programs. Is there a way to disable that with an x-property so that it only uses RAW + LZ4? Is this a bad idea?
  1. Does RAW support some kind scrolling magic? I saw some tickets that seemed to imply yes, but I did some experimentation where I scrolled a few lines in an xterm window with scroll and compress debug on. My interpretation of the debug is that XPRA sends a RAW of the whole window and only does scrolling when it briefly switches to video encoding, but I'm not at all certain.
  1. Your mention of double-buffering sounds very interesting to me. I just did an experiment: I screen grabbed my web browser having the XPRA bug tracker loaded and scrolled about 5% and did another screen grab. When I xz them individually the PPM file compresses to ~ 50K. When I xz the concatenation of them it compresses to ~ 60k. Does (or can) (or would it make sense for) XPRA to exploit this kind of effect with double-buffering? (Honestly, I'm not 100% sure that what I'm saying makes sense, but the idea of compressing a "delta" sounds really nice).

Alternatively I could tell my users something like "use GNU screen for text and xpra for graphics," but they all seem to dislike GNU screen, whereas they seem to like things like XPRA, NX and VNC. I might be able to sell them on this, however, because XPRA is nicely rootless.

Anyway, thanks again for all your help!

comment:3 Changed 15 hours ago by Antoine Martin

The flicker between lossy and RAW can be unpleasant with terminal-like programs. Is there a way to disable that with an x-property so that it only uses RAW + LZ4? Is this a bad idea?

The best way would be to ensure that we tag the terminals as text applications - that should already be the case.
Under normal conditions, this should result in lossless packets and therefore no flickering.

Does RAW support some kind scrolling magic? I saw some tickets that seemed to imply yes, but I did some experimentation where I scrolled a few lines in an xterm window with scroll and compress debug on. My interpretation of the debug is that XPRA sends a RAW of the whole window and only does scrolling when it briefly switches to video encoding, but I'm not at all certain.

Scrolling detection only kicks in when there are enough updates to the same rectangle. Currently this is done by hooking into the video code path, but this could be changed.

Your mention of double-buffering sounds very interesting to me...
(Honestly, I'm not 100% sure that what I'm saying makes sense, but the idea of compressing a "delta" sounds really nice).

The server-side "double-buffering" allows all sorts of interesting optimizations, it's choosing the right ones that is going to be difficult.
Sometimes the code will end up spending too much time figuring out how best to compress the pixels, rather than just doing it. (ie: that's why we currently don't do scrolling detection outside the video code path)

comment:4 in reply to:  3 Changed 15 hours ago by Nathan Hallquist

The best way would be to ensure that we tag the terminals as text applications - that should already be the case.
Under normal conditions, this should result in lossless packets and therefore no flickering.

I've tried that, but I *thought* I saw it still flicker (and I think I saw it in the compress log). What would is the relevant debug capture to check that I'm tagging it as "text" correctly? Also, I'll make a patch to add the xprop commands to the tray ASAP.

comment:5 Changed 12 hours ago by Nathan Hallquist

When I set the property I get this from the metadata log. Is the "does not support" a problem?

2018-12-10 14:34:25,994 content_type=text
2018-12-10 14:34:25,994 updateprop(content-type, text) previous value=None
2018-12-10 14:34:25,994 updating metadata on WindowModel(0x800022): <GParamBoxed 'content-type'>
2018-12-10 14:34:25,995 make_metadata: client does not support 'content-type'
2018-12-10 14:34:25,995 make_metadata(2, WindowModel(0x800022), content-type)={}
Last edited 11 hours ago by Nathan Hallquist (previous) (diff)

comment:6 Changed 11 hours ago by Antoine Martin

content_type=text

I assume this is for a terminal. Then that's what you want to see.

Is the "does not support" a problem?

No. That just means the client doesn't use this attribute so it isn't sent.

Note: See TracTickets for help on using tickets.