0.8.1: text flickery with x264 and min-quality<70

[totaam]

Issue migrated from trac ticket # 245

component: core | priority: major | resolution: wontfix

2013-02-04 03:02:45: onlyjob created the issue

---

With 0.8.0 and 0.8.1 I experience text "flickery" (visual distortion) in kate with "x264" encoding and min-quality < 70.

With several paragraphs of text in kate all text is flashing in the rhythm of cursor flashing. Setting min-quality to 70 is enough to fix the problem.

[totaam]

2013-02-04 04:09:11: antoine changed status from new to accepted

[totaam]

2013-02-04 04:09:11: antoine changed owner from ** to antoine

[totaam]

2013-02-04 04:09:11: antoine commented

---

70 is the minimum quality level for YUV422, below that you would be using YUV420 colour subsampling.

What is strange is that you get a full window refresh with just a cursor change. I guess that kate is updating the whole line or something, so we end up with a full window refresh rather than a small lossless (png/rgb24) region. Will test.

[totaam]

2013-02-06 17:12:45: antoine commented

---

Just tested and I managed to reproduce the flickering issue in Kate. That's because the Kate application re-paints the whole line (or more?) every time the cursor blinks - so xpra does a full window refresh using x264. Then
shortly after the auto-refresh kicks in and does a lossless refresh at
high quality.
The flickering is due to the difference in quality between regular
frames and almost-lossless frames.

I'm trying to find out why the quality isn't higher on "auto" when Kate
is idle (just the cursor blinking), "xpra info" reports a quality of about ~80% when it looks like it should go much higher (and therefore avoid all flickering by virtue of already being lossless).

PS: The problem manifests even more wildly if kate has spellchecking enabled and some words are underlined.

[totaam]

2013-03-20 13:51:46: antoine changed status from accepted to closed

[totaam]

2013-03-20 13:51:46: antoine changed resolution from ** to wontfix

[totaam]

2013-03-20 13:51:46: antoine commented

---

I don't think there is much we can do about this at all, when using YUV422 or YUV420, the colour subsampling will do this - the only way to avoid it is to not use it: setting a quality high enough so that YUV444 is used (by default the threshold is at 90%).

---

The quality and min-quality options can be set:

• via /etc/xpra/xpra.conf
• via ~/.xpra/xpra.conf
• via the command line
• via the applet