xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 9 years ago

Closed 9 years ago

Last modified 16 months ago

#245 closed defect (wontfix)

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

Reported by: onlyjob Owned by: Antoine Martin
Priority: major Milestone: 0.8
Component: core Version: trunk
Keywords: Cc:


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.

Change History (4)

comment:1 Changed 9 years ago by Antoine Martin

Owner: set to Antoine Martin
Status: newaccepted

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.

comment:2 Changed 9 years ago by Antoine Martin

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.

Last edited 9 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 9 years ago by Antoine Martin

Resolution: wontfix
Status: acceptedclosed

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

comment:4 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.