A couple of releases back we changed Xvnc to have an outgoing send buffer to avoid stalling when a client wasn't receiving data fast enough. Unfortunately the buffer size is fixed so it can still happen for large updates (e.g. a full screen refresh).
We should look at increasing the buffer size, probably dynamically as needed.
This should be fixed upstream as of this PR:
I have now gone through all the commits in PR mentioned in comment 1.
The changes all in all look fine but explicitly testing all changes made would be pretty time-consuming, we will therefore rely on the regression tests done for bug 7785 (which cover all relevant general cases needed for this bug). Also, note that the beta and subsequent stable release has been out for a while without any issues related to this change reported.
Thus, what remains to be tested is the general scope of this bug.
I have performed some quantitative performance measurements with
`x11perf', comparing the performance of Xvnc over a bandwidth throttled
This was done using server build #2375 and server release 4.13.0 running
on Fedora Server 35, both connected to using client build #2287. Since
we want to quantify X server performance for large updates (as mentioned
in comment 0) the benchmarks were run with a high entropy full-screen
RGB noise (changing 60 times per second) in the background with a
session resolution of 3000x2000 to ensure the following:
• That every update would require the whole screen to be sent
• That every update would be hard for the JPEG algorithm to compress
effectively, thus making it large in terms of bytes sent
The benchmarks were performed using the following command: `x11perf
-repeat 100 -time 1 -scroll500' with the following aggregate results:
│ 10 mbit/s 1000 mbit/s
#2375 │ 11200 iters/s 8180 iters/s
4.13.0 │ 6680 iters/s 6820 iters/s
The specific benchmark `scroll 500' was chosen rather arbitrarily since
we are looking for complete stalls of the X server and not how
performant it is in a specific area.
I have not performed any proper statistical analysis of the overall
benchmark results, but one thing that stands out is the sheer amount of
outliers in the 10 mbit/s 4.13.0 measurements. If we remove these
outliers (making up approx. 1/10 of the measurements) we get a similar
aggregate result as for the 10 mbit/s #2375 series. My conclusion is
that these outliers (which are not at all present in #2375) are the
result of the stalls mentioned in comment 0.
Worth noting is that these measurements are relatively prone to
confirmation bias since the newer of these have had a lot of its third
party components updated (such as its X server and libjpeg) and not just
TigerVNC. Nonetheless, what we are looking for in practice is a large
enough performance increase to motivate a somewhat generally formulated
release note about increased performance.
After some discussion, we've decided to leave out the release note for this one since this bug is of the more theoretical kind even though we see a decent increase in performance under certain conditions. Marking as closed!