Excessive blurriness with min-quality at 70

[totaam]

Issue migrated from trac ticket # 1265

component: server | priority: major | resolution: fixed | keywords: blurriness

2016-07-22 23:23:16: maxmylyn created the issue

---

Ignoring that using min-quality at 70 is a bad idea, this is one that's plagued our stuff for quite a while and I finally managed to repro it with Vanilla Xpra. I'll attach a screenshot and xpra info to this ticket.

Server is a trunk Fedora 23 r13078, and client is a trunk Win8.1 r13012.

Server is started with:

xpra start :13 --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --start-child=xterm --start-child=xterm

And the client is connected with:

set XPRA_B_FRAMES=0

(running without B Frames because they're still causing some weird paint issues)

Xpra_cmd attach tcp:ip:2200 --min-quality=70

Repro is mostly sporadic, but generally we see it when scrolling on text-only webpages when the browser is larger than 1080p - I'm using google-chrome fullscreen on a 1440p. The problem with the sporadic-ness is that it's hard to give a step-by-step repro to reliably trigger it every time. However, once you trigger it, it aggressively becomes blurry while scrolling and "sticks" for about a second until it refreshes losslessly.

Long story short it's painting with a quality way below 70 when the min-quality is set to 70. It looks like there is a tiny corner case where the quality can drop below this minimum.

Unfortunately, it seems to sort itself out after a short period of time. With our stuff, it takes several minutes (as in >15) before it snaps out, but just Xpra and Chrome, it sorted itself out within a minute or two.

However, I was able to grab an xpra info while it was "stuck" blurry for a sec.

Tagging as server as I'm not entirely sure if it's encodings or not.

[totaam]

2016-07-22 23:23:50: maxmylyn uploaded file Excessive blurry with 70 min-quality.png (2306.5 KiB)

Described blurriness - When I said excessive, I meant very excessive. This is with a min-quality of 70.

[totaam]

2016-07-22 23:25:01: maxmylyn uploaded file xprainfo.txt (143.1 KiB)

Xpra info piped while it was "stuck" blurry.

[totaam]

2016-07-22 23:27:13: maxmylyn uploaded file xprainfo2.txt (151.8 KiB)

an Xpra info when it had snapped back to "normal" to compare with

[totaam]

2016-07-23 09:46:55: antoine changed owner from antoine to maxmylyn

[totaam]

2016-07-23 09:46:55: antoine commented

---

Long story short it's painting with a quality way below 70 when the min-quality is set to 70
[[BR]]
How did you ascertain this? The command line you posted does not specify min-quality=70.
You would need to log the -d compress server log to see the speed and quality settings actually used for each video screen update. (or -d paint client side, which may be more verbose than desired)
[[BR]]

..this is one that's plagued our stuff for quite a while...
[[BR]]
This looks like a clear duplicate of #967: the main difference between the blurry state and the non-blurry state is the use of YUV420P colour subsampling:

window.4.csc.dst_format=YUV420P

The fact that this is triggered by scrolling makes me think that this is exactly the same issue and conclusion as #800#comment:18 / #967.

[[BR]]

(running without B Frames because they're still causing some weird paint issues)
[[BR]]
The only problems reported so far have been related to video region detecting the most of the window as video, which leads us back to the conclusion in #800#comment:18.
Is there anything else?
Please try not to disable b-frames unless there is a different problem with that feature, one that is not currently recorded in #800. At least not until #1257 is tested and closed. (and maybe wait for #1232 too..)

---

[[BR]]

Unfortunately, it seems to sort itself out after a short period of time. With our stuff, it takes several minutes (as in >15) before it snaps out, but just Xpra and Chrome, it sorted itself out within a minute or two.
[[BR]]
Now this looks like a separate issue that needs fixing: if the window stops re-painting (or re-painting a lot less.. which is much harder to detect unfortunately), we should refresh more quickly than after one second and we should raise the quality back up much more quickly.

Can we track this problem here and change the ticket title, then track the video-region issue in #967?

[totaam]

2016-07-25 18:17:03: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2016-07-25 18:17:03: maxmylyn edited the issue description

[totaam]

2016-07-25 18:17:03: maxmylyn commented

---

How did you ascertain this? The command line you posted does not specify min-quality=70.

[[br]]

Sorry, copied wrong - I had a --min-quality=70

[[br]]

Unfortunately, it seems to sort itself out after a short period of time. With our stuff, it takes several minutes (as in >15) before it snaps out, but just Xpra and Chrome, it sorted itself out within a minute or two.

[[br]]

I should clarify here, in case it's not clear enough. "Normal" operation is that it does not snap to that level of blurry ever - it always stays crisp and easy to read.

[[br]]

Can we track this problem here and change the ticket title, then track the video-region issue in #967?

[[br]]

Sounds good to me. I'll defer to you to update this ticket's info as you know more about the underlying issue. I'll talk with Alex and now that all of QA (myself included) is completely back from vacation we can actually have time to catch up on our tickets here.

[totaam]

2016-07-26 09:40:09: antoine changed owner from antoine to maxmylyn

[totaam]

2016-07-26 09:40:09: antoine commented

---

Sorry, copied wrong - I had a --min-quality=70

.. it's painting with a quality way below 70
[[BR]]
The question from comment:1 remains: How did you ascertain this?
What value is actually being used?

[[BR]]

"Normal" operation is that it does not snap to that level of blurry ever
[[BR]]
Normal being with or without min-quality set to 70?
And abnormal is occasionally when scrolling on text-only webpages when the browser is larger than 1080p, right?

[totaam]

2016-07-26 17:17:33: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2016-07-26 17:17:33: maxmylyn commented

---

How did you ascertain this?
What value is actually being used?

[[br]]

Both the tray menu min-quality setting and the Xpra Info I attached to this comment say that the min-quality is set to 70.

[[br]]

Normal being with or without min-quality set to 70?
And abnormal is occasionally when scrolling on text-only webpages when the browser is larger than 1080p, right?

[[br]]

Normal being with the min-quality set to 70. Leaving it at 40 will drop the quality noticeably periodically(expected), but it does perform much better.

And yes, scrolling on text-only webpages when the browser is at or larger than 1080p.

[totaam]

2016-07-27 13:30:17: antoine changed owner from antoine to maxmylyn

[totaam]

2016-07-27 13:30:17: antoine commented

---

Both the tray menu min-quality setting and the Xpra Info I attached to this comment say that the min-quality is set to 70.
[[BR]]
That is not enough. You claim that the quality is lower, as per comment:1 : You would need to log the -d compress server log to see the speed and quality settings actually used for each video screen update. (or -d paint client side, which may be more verbose than desired)

[[BR]]

Normal being with the min-quality set to 70.
[[BR]]
Confusing: "normal operation" should be default settings.

[totaam]

2016-07-29 20:54:03: maxmylyn commented

---

Update:

cannot reproduce the state I had in the original post as of 13131; despite trying for the last two full work days. Because of that, I cannot get the -d compress logs.

[totaam]

2016-10-28 20:02:52: maxmylyn commented

---

Still unable to reproduce as of r14322 trunk Fedora 24 server and client.

Tempted to close this, but I will give it a closer look this afternoon since I have nothing queued up for myself at the moment and can bang on it a little bit.

[totaam]

2016-12-26 09:39:45: antoine changed status from new to closed

[totaam]

2016-12-26 09:39:45: antoine set resolution to fixed

[totaam]

2016-12-26 09:39:45: antoine commented

---

Not heard back, closing.