Xpra: Ticket #694: auto-refresh kicks in too early

Tested with glxspheres, which generates a constant stream of screen updates. The auto-refresh should never get a chance to kick in.

This costs us a lot of bandwidth, and makes the picture stutter.



Fri, 26 Sep 2014 05:59:07 GMT - Antoine Martin: attachment set

this patch fixes the refresh by delaying it for as long as window updates keep coming in


Fri, 26 Sep 2014 16:25:30 GMT - Antoine Martin: owner changed

Well, r7813 is a bit big, but I couldn't find a clean way to do this without making quite a few changes and adding a lot of comments to explain what is going on. It's not simple because the first half happens in the compression thread, but the actual refresh happens in the UI thread, and we don't want to use locking which would slow things down.

The real problem here is that we have different subsystems all competing for encoding decisions, they all do slightly different things and they all have an impact on each other:

What we had before was refreshing too often, but it is possible that with this change we may not refresh enough now.. (at least not as much as before) If window updates keep coming through, we may keep delaying the window refresh indefinitely. It tries to avoid that by delaying less for small updates than larger ones, and smaller updates are also less likely to be using lossy encodings in the first place.

Ideally, we could just keep track of every single region we process, when it got updated, at what quality, etc. Then we could easily determine when something needs a refresh. But this could quite quickly end up using up more CPU time and memory than just actually doing the work... (as we already know that the rectangle calculation code isn't very fast: #620)

With the old code, I could see the auto-refresh kicking in despite new full-window updates happening around the same time. Causing a sort of stutter in middle of fast moving frames. With this new code, I see instead:

refresh_timer_function: rescheduling auto refresh timer with extra delay 292ms
auto refresh:   vp8 screen update (quality=  0), re-scheduling refresh \
    (due in 299ms, 39ms added - sched_delay=300, pct=100, batch=35.6382594128) ...
auto refresh:   vp8 screen update (quality=  0), re-scheduling refresh \
    (due in 299ms, 33ms added - sched_delay=300, pct=100, batch=35.6382594128) ...

etc.

@afarr: can you break it? can you verify things are "better" than they were?


Sat, 27 Sep 2014 01:23:47 GMT - alas:

Can't seem to break it, despite some effort.

It is better, with windows client at least (and a relatively weak windows 7 client host at that).

I'll test again with an osx client when I get the chance.


Sun, 28 Sep 2014 11:10:08 GMT - Antoine Martin: status changed; resolution set

Backport in r7819. This will do for now.


Tue, 06 Jan 2015 12:37:25 GMT - Antoine Martin:

Related: r8407, r8410.


Sat, 23 Jan 2021 05:03:12 GMT - migration script:

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