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.
this patch fixes the refresh by delaying it for as long as window updates keep coming in
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?
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.
Backport in r7819. This will do for now.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/694