|Summary:||deferred updates misbehaves with large updates (and is currently "disabled")|
|Product:||ThinLinc||Reporter:||Pierre Ossman <ossman>|
|Component:||VNC||Assignee:||Pierre Ossman <ossman>|
* 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)
|Bug Depends on:||7158|
|Bug Blocks:||5106, 2931|
Description Pierre Ossman 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 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 2017-02-24 13:28:11 CET
Merged upstream: https://github.com/TigerVNC/tigervnc/pull/421
Comment 3 Pierre Ossman 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 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 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).