Xpra: Ticket #1175: 0.16.3: lossy encoding on local attach

When I attach to local session (xpra attach :22) lossy encoding is used which manifests with visual artefacts.

Why not use loseless encoding like raw RGB by default on local connection? It works faster and it used to be default behaviour in previous versions of Xpra.

I can override current behaviour if I attach with --no-mmap or with --encoding rgb.



Mon, 18 Apr 2016 11:19:00 GMT - Antoine Martin: owner changed

Local connections should be using mmap, unless you use --no-mmap. And why would you? I really don't see why it would have the opposite effect.

Lossy encodings are unlikely to be used over a fast local connection, though they may get used for the first few frames.


Mon, 18 Apr 2016 12:23:28 GMT - onlyjob:

Maybe it is just those first few frames but effect is quite obvious.

I had to resort to --no-mmap in order to enforce loseless encoding to get rid of visual artefacts as well as to confirm the nature of the problem. Before 0.16 I did not see visual artefacts on local connections...


Tue, 19 Apr 2016 01:52:53 GMT - Antoine Martin:

Like I said, this does not make any sense. mmap is lossless, always. Whatever you're doing, you're not really telling - no command lines or versions, no bug report data, etc.. so I will probably close this as needinfo.


Tue, 19 Apr 2016 04:41:04 GMT - onlyjob:

If mmap is loseless then why do I see artefacts that disappear with --encoding rgb? Apparently mmap is _not_ loseless, not anymore, not in 0.16.

Whatever you're doing, you're not really telling - no command lines or versions, no bug report data, etc.. so I will probably close this as needinfo.

Frankly that kind of attitude discourages me from reporting Xpra bugs. Why do we have to do this dance every time? I already told you everything relevant about the problem. I start local server xpra start :22 and an application in it (e.g. Firefox). I attach as simple as xpra attach :22 and observe grey menu entries (Encoding, Quality, Speed, etc) that makes me think that mmap mode is in use. When I scroll a page in Firefox I see visual distortion that was not there in 0.15 and earlier and that disappear if I explicitly enforce loseless encoding. I don't know why it doesn't make sense to you and I have no time to deal with denial. Now when I repeated myself I hope it really helped to better understand the problem. I have nothing more to add but I can answer your questions or try something that you might have to suggest...


Tue, 19 Apr 2016 06:05:43 GMT - Antoine Martin:

If mmap is loseless then why do I see artefacts that disappear with --encoding rgb?


That will be because you are not using mmap in the first place. Like I said, mmap is always lossless - as it cannot be any other way. "rgb via mmap" is the encoding.

Having the command output or even just xpra info would probably be enough to confirm that. Here are mine which shows that everything is working as it should:

$ xpra attach |& grep mmap
enabled fast mmap transfers using 256MB shared memory area
 no need for scaling with mmap
$ xpra info | grep mmap=
network.mmap=True
window.1.mmap=True
window.1.total_frames.mmap=6
window.1.total_pixels.mmap=460065


Frankly that kind of attitude discourages me from reporting Xpra bugs.


Well, that escalated quickly.


Why do we have to do this dance every time?


Everybody does. You are not special.

I don't have time to try to figure out the details people aren't giving me. If I try and it works, I assume you're leaving something out or just doing it wrong.

I already told you everything relevant about the problem.


Blatantly not: pretty much every single item found on the wiki/ReportingBugs guidelines is missing.


Tue, 19 Apr 2016 08:25:37 GMT - onlyjob:

xpra attach :22 |& grep mmap
2016-04-19 18:27:14,747 enabled fast mmap transfers using 256MB shared memory area
2016-04-19 18:27:14,771  no need for scaling with mmap
xpra info | grep mmap=
network.mmap=True
window[8].encoding.mmap=True
window[110].encoding.mmap=True

You are not special.

Nope. Everyone is special. :)

pretty much every single item found on the wiki/ReportingBugs guidelines is missing.

Noted. See below (keyboard mapping information omitted).

Edit: moved to attachment/ticket/1175/bug-report.txt


Tue, 19 Apr 2016 08:50:52 GMT - Antoine Martin: attachment set

moving the large bug report data to an attachment


Tue, 19 Apr 2016 09:03:25 GMT - Antoine Martin:

From the bug report data, I see that mmap IS enabled but that video region detection kicked in, so we used a video encoding for that region. r12439 disables video region detection when mmap is in use (since it isn't needed or helpful), does it help? Maybe region detection is more aggressive in 0.16.x - it shouldn't be. Or maybe the application just repaints too much, more likely.

Related tickets: #967, #410, #596.


Tue, 19 Apr 2016 10:56:07 GMT - onlyjob: status changed; resolution set

Yay, Antoine, r12439 works perfectly: I can't reproduce the problem any more and it seems to work faster. :) Very happy. :)

I did not expect that you'd be able to spot anything useful in debug info as I could see the issue only during scrolling (which I was not doing when I took bug report dump). Duly noted for the future.

Thanks very much!


Sat, 23 Jan 2021 05:17:01 GMT - migration script:

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