Xpra: Ticket #1265: Excessive blurriness with min-quality at 70

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.



Fri, 22 Jul 2016 22:23:50 GMT - J. Max Mena: attachment set

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


Fri, 22 Jul 2016 22:25:01 GMT - J. Max Mena: attachment set

Xpra info piped while it was "stuck" blurry.


Fri, 22 Jul 2016 22:27:13 GMT - J. Max Mena: attachment set

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


Sat, 23 Jul 2016 08:46:54 GMT - Antoine Martin: owner changed

Long story short it's painting with a quality way below 70 when the min-quality is set to 70


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)

..this is one that's plagued our stuff for quite a while...


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 ticket:800#comment:18 / #967.


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


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 ticket: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..)



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.


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?


Mon, 25 Jul 2016 17:17:03 GMT - J. Max Mena: owner, description changed

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


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


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.


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.


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


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.


Tue, 26 Jul 2016 08:40:09 GMT - Antoine Martin: owner changed

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

.. it's painting with a quality way below 70


The question from comment:1 remains: How did you ascertain this? What value is actually being used?


"Normal" operation is that it does not snap to that level of blurry ever


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?


Tue, 26 Jul 2016 16:17:32 GMT - J. Max Mena: owner changed

How did you ascertain this?

What value is actually being used?


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.


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?


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.


Wed, 27 Jul 2016 12:30:16 GMT - Antoine Martin: owner changed

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.


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)


Normal being with the min-quality set to 70.


Confusing: "normal operation" should be default settings.


Fri, 29 Jul 2016 19:54:02 GMT - J. Max Mena:

Update:

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


Fri, 28 Oct 2016 19:02:52 GMT - J. Max Mena:

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.


Mon, 26 Dec 2016 09:39:44 GMT - Antoine Martin: status changed; resolution set

Not heard back, closing.


Sat, 23 Jan 2021 05:19:32 GMT - migration script:

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