0.16.3: lossy encoding on local attach

[totaam]

Issue migrated from trac ticket # 1175

component: encodings | priority: minor | resolution: fixed

2016-04-18 11:39:28: onlyjob created the issue

---

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.

[totaam]

2016-04-18 12:19:01: antoine changed owner from antoine to onlyjob

[totaam]

2016-04-18 12:19:01: antoine commented

---

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.

[totaam]

2016-04-18 13:23:29: onlyjob commented

---

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

[totaam]

2016-04-19 02:52:54: antoine commented

---

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.

[totaam]

2016-04-19 05:41:05: onlyjob commented

---

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

[totaam]

2016-04-19 07:05:43: antoine commented

---

If mmap is loseless then why do I see artefacts that disappear with --encoding rgb?
[[BR]]
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

[[BR]]

Frankly that kind of attitude discourages me from reporting Xpra bugs.
[[BR]]
Well, that escalated quickly.

[[BR]]

Why do we have to do this dance every time?
[[BR]]
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.
[[BR]]

I already told you everything relevant about the problem.
[[BR]]
Blatantly not: pretty much every single item found on the ReportingBugs guidelines is missing.

[totaam]

2016-04-19 09:25:37: onlyjob commented

---

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]

[totaam]

2016-04-19 09:50:52: antoine uploaded file bug-report.txt (88.9 KiB)

moving the large bug report data to an attachment

[totaam]

2016-04-19 10:03:26: antoine commented

---

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.

[totaam]

2016-04-19 11:56:08: onlyjob changed status from new to closed

[totaam]

2016-04-19 11:56:08: onlyjob set resolution to fixed

[totaam]

2016-04-19 11:56:08: onlyjob commented

---

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!