xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

#1175 closed defect (fixed)

0.16.3: lossy encoding on local attach

Reported by: onlyjob Owned by: onlyjob
Priority: minor Milestone: 0.17
Component: encodings Version: 0.16.x
Keywords: Cc:

Description

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.

Attachments (1)

bug-report.txt (88.9 KB) - added by Antoine Martin 4 years ago.
moving the large bug report data to an attachment

Download all attachments as: .zip

Change History (9)

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to onlyjob

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.

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

comment:3 Changed 4 years ago by 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.

comment:4 Changed 4 years ago by 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...

comment:5 Changed 4 years ago by 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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 4 years ago by 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

Last edited 4 years ago by Antoine Martin (previous) (diff)

Changed 4 years ago by Antoine Martin

Attachment: bug-report.txt added

moving the large bug report data to an attachment

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by onlyjob

Resolution: fixed
Status: newclosed

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!

Note: See TracTickets for help on using tickets.