I observe a similar issue sometimes when resizing the remote desktop,
and if it's the same issue, then it is due to the updated RFB flow
control algorithms
(https://github.com/TurboVNC/turbovnc/commit/a0f5670ecc42538f95f56ee81a885c6ba32916f1).
If the flow control statistics are reset due to an idle connection, then
a situation can occur in which the connection is marked as congested but
no ETA is provided for when it will become uncongested. That results in
undelivered framebuffer updates.
Referring to:
https://github.com/TigerVNC/tigervnc/commit/a99d14d1939cb2338b6268d9aebe3850df66daed#r57748408
I have asked the TigerVNC developers for clarification but have not
heard back. My next step is to instrument the TigerVNC Server code and
attempt to figure out why their server doesn't seem to suffer from the
same symptoms, even though it has the same algorithmic flaw (or at least
what I perceive to be a flaw, but maybe I'm missing something.)
DRC
On 10/22/21 2:42 PM, joa...@verona.se wrote:
Hello,
I'm experiencing som problems with screen updates in turbovnc "3.0
evolving", rpm turbovnc-2.2.80-20211011. I'm using fedora 35 on the
client, 34 on the server. The repaint problem happens mostly in emacs,
because thats what i use the most.
If I open a shell buffer and do a "ls" the output seems to happen at
the server, but the repaint isnt propagated to the client. If I wiggle
the mouse cursor a bit, the screen update do happen.
I've tried some different configurations, like changing the update
frequency, encoding quality and so on, and the problem doesnt happen.
Any hints?
Regards
/Joakim/
--
You received this message because you are subscribed to the Google Groups "TurboVNC
User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to turbovnc-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/493a28d6-173e-dbe7-bc7d-43937f292e1c%40virtualgl.org.
