Bug 5719 - deferred updates misbehaves with large updates (and is currently "disabled")
Summary: deferred updates misbehaves with large updates (and is currently "disabled")
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: pre-1.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Pierre Ossman
URL:
Keywords: prosaic
Depends on: 7158
Blocks: performance 2931
  Show dependency tree / graph
 
Reported: 2015-11-18 14:36 CET by Pierre Ossman
Modified: 2018-09-24 14:07 CEST (History)
1 user (show)

See Also:
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
Add an attachment (proposed patch, testcase, etc.)

Description Pierre Ossman cendio 2015-11-18 14:36:19 CET 
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 Pierre Ossman cendio 2016-10-10 15:48:38 CEST 
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 Pierre Ossman cendio 2017-02-24 13:28:11 CET 
Merged upstream:

https://github.com/TigerVNC/tigervnc/pull/421
Comment 3 Pierre Ossman cendio 2018-09-24 13:51:18 CEST 
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 Pierre Ossman cendio 2018-09-24 14:04:53 CEST 
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 Pierre Ossman cendio 2018-09-24 14:07:24 CEST 
> * 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).
Note You need to log in before you can comment on or make changes to this bug.