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: https://github.com/TigerVNC/tigervnc/pull/1029
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 connection. 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!
