When running ThinLinc over a low bandwidth link and there aren't that many updates on screen, the auto mode tends to flip-flop between color modes. This of course makes things entirely unusable, which defeats the point of the auto mode. There are two theories as to why this happens: * When chaning modes, the entire screen is updated. This burst of data fools the algorithm to thinking that the bandwidth is low and changes back to the low quality mode. * The algorithm has trouble determining bandwidth when the screen changes are too small. The theory is that the entire update fits inside a single IP packet, so there is no way to determine how fast it was received (first and last byte arrives at the same time as far as vncviewer is concerned). Tunnling over SSH might make this worse. We should investigate what is going on here and see if we can fix it.
> > * When chaning modes, the entire screen is updated. This burst of data fools > the algorithm to thinking that the bandwidth is low and changes back to the low > quality mode. > This got fixed some time ago. It is still getting fooled by (primarily) small updates though.
This issue hasn't been reported in years, so it doesn't seem to be an issue anymore. Also, the next vendor drop will get a more smoothed measuring system: https://github.com/TigerVNC/tigervnc/commit/2354ce7404b8bacced3249e9c9787a12de307d2a#diff-ede54057f2c8eb129e3974dcc411286681ef8cb00f7947c273f957216919faab
