Closed pH5 closed 2 months ago
The reason why I didn't implement this already is that with multiple in-flight buffer requests, you basically get continuous updates plus rudimentary congestion control. However, now that SO_SNDBUF
has been set to a lower value, HOL blocking on the host should be taken care of, although buffer bloat somewhere in between is a possibility, I suppose.
Does this improve some performance metric for some clients? I suppose that some clients might not pipeline requests, but support continuous updates instead.
I don't have any hard metrics, I just noticed support in the client. Let's bench this for now.
I've been looking into this a little bit closer lately and it turns out that clients generally don't pipeline their requests and those who do only keep a backlog of 2 or 3 requests.
It's probably easier to just add this extension than to go around adding 20 extra requests (because that's what's needed when the RTT is 300 ms) to every open source client out there.
It could also be argued that keeping a backlog of multiple requests isn't very robust because you don't know the frame rate or the latency.
This is an interesting read: https://github.com/TigerVNC/tigervnc/wiki/Development%3A-Latency
Thanks!
Support sending continuous framebuffer updates when requested via the EnableContinuousUpdates message.