xpra icon
Bug tracker and wiki

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


Changes between Version 1 and Version 2 of Ticket #670


Ignore:
Timestamp:
09/05/14 06:14:15 (7 years ago)
Author:
Antoine Martin
Comment:

On a 1080p screen with a gvim window taking up half the screen, with a fairly large file open, a single click on the scrollbar causes 320 damage events! All but 5 of those repaints are exactly 1 line in height (15 pixels high), many are one or two characters wide.. The 5 odd ones do contain an almost-full window repaint, right at the beginning. 69 repaints are a single character wide (8x15)

What a really odd way of painting the screen!

So the good news is that I have a workaround:

XPRA_FORCE_BATCH=1 xpra start ...

Will start the server with force-batch mode, which means that even when things are going well (no pixel backlog or network congestion) we will wait before encoding the pixels, which allows us to batch them up together. On my system, it makes things usable again.

cesarkawakami: does that improve things for you?


As for a more proper fix for this: I'm not too sure how to go about it. Should we always enable batching by default? (vnc does) We would lose a tiny bit of latency in some cases (well behaved applications) just to workaround applications with pathological behaviour...

Another approach would be to enable batching when we detect a damage storm like this one. Which is probably the better option, but may not be suitable for a 0.14.x backport.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #670 – Description

    v1 v2  
    11Reproduction steps:
    22
    3 *
     3* start server:
    44{{{
    55xpra start :100 --start-child='executable' --no-speaker -d encoding
    66}}}
    77where executable might be gvim or emacs when configured for GUI use
    8 *
     8* attach client in rgb mode:
    99{{{
    1010xpra attach :100 --encoding=rgb -z 0