Recently I tried 0.11.3 over (slow) WAN connection and there was a problem with H.264 encoding on some applications. Notably I was trying to work with
kmail with minimum_speed=low_bandwidth and minimum_quality either "low" or "average". As expected initially app. window rendered with very low quality (unreadable text) which improved after several seconds. The problem was that full window refresh were kicking again by merely moving mouse cursor over app. window so visual presentation was degrading window-wide making all text unreadable then seconds later improving to the point when text became readable again only for few seconds then cycle repeated over and over.
Bad-goog-bad cycle forced me to switch encoding to JPEG where situation was slightly better because minimum quality did not make text completely unreadable. There were seemingly unnecessary full window redraws but I could still read the text.
I'm not sure whether the issue is due to applications doing full window redraw or due to (incorrect?) detection of new content or because of too low minimum quality settings in H.264. It could be combination of any of those three or perhaps the lack of detection for changes to avoid re-sending the same data when window simply re-painted exactly the same content...
It is difficult to say, I don't have
kmail setup to try it out.
It does sound like
kmail is redrawing parts of the screen unnecessarily (many applications do this unfortunately), 0.12 / trunk has a few changes in this area so it is worth a try to see if it improves things:
JPEG gives you a better experience, then I think you should still be able to go with
h264 and just bump the minimum quality higher. Bandwidth consumption should be lower than with
JPEG, it is just a case of finding the quality level that makes this usable. (and this varies widely: text based applications have a very different profile than say, games or graphical apps)
It is also worth noting that by setting the speed to low-bandwidth, things may actually get worse for some applications (especially those that send lots of small updates): as it takes much longer to compress each frame, more updates have time to accumulate, when we do get around to processing them there are too many and we choose a fullscreen update to try to optimize... Were the results on default settings worse?
There may be more information in
xpra info for the window you are interested in: actual encodings used, etc.
kate have a similar problem. To reproduce paste some text, select some and move mouse over the window. Selected area will appear with degraded quality, which will improve and then degrade again etc.
Bumping minimum h264 quality helps. Default settings are not much better than "low-bandwidth" -- perhaps there is small benefit in regards to bandwidth as it feels like quality improves slightly faster. The problem though is that as soon as quality improves it goes back to bad (unreadable) state to repeat redraw cycle all over...
I didn't have a chance to try 0.12 yet...
xpra info when the window is shown with degraded quality.
kate does repaint a lot of things on screen, and on a slow link (where the batch delay is going to be high) you are more likely to get a full screen refresh, and therefore more likely to see a subsampled frame. As I said above, v0.12 should be better at this.
But overall I don't think this is a bug: on a slow link, something has to give. By default we lower both the speed (higher latency to get better compression) and the quality (lower quality to get better compression). If you want to keep a higher quality, the option is there. Some users do want to sacrifice quality for better framerate and others do not, that's why the options are there..
Can you suggest what we should be doing different?
Can I close this? (see previous comments)
Yes please close. I didn't have a chance to try 0.12 yet... Is it detect (and skip) refreshes with no changes?
Detecting "no change" is *hard*, video encodings do it for us as part of their motion detection (no motion in this case). But the problem is that by the time you get there, you've already decided to send a video frame, and so you may already be committed to subsampling its pixels, which means that you will gain nothing.
What 0.12 does is:
Feel free to re-open if you feel that we should do better on automatic mode. Though it can be argued that problematic applications (
kate has been added to Application Quircks) should be handled manually rather than risking degrading the default behaviour.
Makes sense. Thank you for detailed explanation -- it helps to understand what's going on and the challenges. Let's close unless there are any new improvement ideas.
I'm closing as "worksforme" for lack of a better option, things aren't fixed, just a tad better hopefully.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/522