xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 3 years ago

#1265 closed defect (fixed)

Excessive blurriness with min-quality at 70

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: major Milestone: 1.0
Component: server Version: trunk
Keywords: blurriness Cc:

Description (last modified by J. Max Mena)

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.

Attachments (3)

Excessive blurry with 70 min-quality.png (2.3 MB) - added by J. Max Mena 4 years ago.
Described blurriness - When I said excessive, I meant very excessive. This is with a min-quality of 70.
xprainfo.txt (143.1 KB) - added by J. Max Mena 4 years ago.
Xpra info piped while it was "stuck" blurry.
xprainfo2.txt (151.8 KB) - added by J. Max Mena 4 years ago.
an Xpra info when it had snapped back to "normal" to compare with

Change History (11)

Changed 4 years ago by J. Max Mena

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

Changed 4 years ago by J. Max Mena

Attachment: xprainfo.txt added

Xpra info piped while it was "stuck" blurry.

Changed 4 years ago by J. Max Mena

Attachment: xprainfo2.txt added

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

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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?

comment:2 Changed 4 years ago by J. Max Mena

Description: modified (diff)
Owner: changed from J. Max Mena to Antoine Martin

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.

Last edited 4 years ago by J. Max Mena (previous) (diff)

comment:3 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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?

comment:4 Changed 4 years ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.

comment:5 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

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.

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

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

comment:8 Changed 3 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Not heard back, closing.

Note: See TracTickets for help on using tickets.