www.cendio.com
Bug 5719 - deferred updates misbehaves with large updates (and is currently "disabled")
: deferred updates misbehaves with large updates (and is currently "disabled")
Status: CLOSED FIXED
: ThinLinc
VNC
: pre-1.0
: PC Unknown
: P2 Normal
: 4.10.0
Assigned To:
:
:
: 7158
: 2931 5106
  Show dependency treegraph
 
Reported: 2015-11-18 14:36 by
Modified: 2018-09-24 14:07 (History)
Acceptance Criteria:
* The server should not send screen changes faster than the configure FrameRate (default 60 Hz) * Lossless refresh updates (bug 2928) should not be limited * Server should not add any delays when it fails to maintain the configured rate (bug described in original comment)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2015-11-18 14:36:19
We fixed the deferred update mechanism in bug 2931 so that it worked reasonably
well. However it got disabled again just a few months later because DRC found
and issue with large updates:

http://thread.gmane.org/gmane.network.vnc.tigervnc.devel/2016

In short, the time needed to compress and send out an update is added on top of
the deferred time, possibly extending that time far beyond what it is
configured to.
------- Comment #1 From cendio 2016-10-10 15:48:38 -------
Attempt at fixing this:

https://github.com/CendioOssman/tigervnc/tree/fps

This changes the deferred system to a repeating timer that clocks out frames.
Seems to work very well, and also mitigates bug 5720.
------- Comment #2 From cendio 2017-02-24 13:28:11 -------
Merged upstream:

https://github.com/TigerVNC/tigervnc/pull/421
------- Comment #3 From cendio 2018-09-24 13:51:18 -------
Overall this feature seems to be working well. I'm seeing two immediate
effects:

 * Reduction in CPU and bandwidth for applications that update very often (> 60
fps). E.g glxgears in my test now uses 14 Mbps instead of 38 Mbps with no
visual difference.

 * Much less tearing

I'm trying to come up with a scenario that tests the original issue though...
------- Comment #4 From cendio 2018-09-24 14:04:53 -------
glxgears in fullscreen seems to provoke the original bug. If I configure 4.9.0
with a deferred update time of 16 ms (should be ~60 fps) I get 35-40 fps in
practice. The new code manages to hit the target much closer with 50-55 fps.
------- Comment #5 From cendio 2018-09-24 14:07:24 -------
> * The server should not send screen changes faster than the configure FrameRate (default 60 Hz)

Yup, works well.

> * Lossless refresh updates (bug 2928) should not be limited

I do indeed gets lots of small refresh updates.

> * Server should not add any delays when it fails to maintain the configured rate (bug described in original comment)

Works well in the glxgears test scenario (see above).