>> I will say that TigerVNC is not tuned for connections that slow. Tuning >> the protocol to be exceptionally "tight" on very low bandwidth >> connections makes it perform miserably slow on faster connections. >> However, I think there is still probably room for improvement. > > I think this is bigger than just a case of sub-optimal tuning. I'll > resume my findings from earlier: > > ssh -C 265 colours = a bit slow but workable > ssh -C 24 bit colour = functional but annoyingly slow > ssh any color depth = absolutely unusably slow , even for debugging > purposes > > Within a factor of 2 all compression options, including raw, are about > equal on ssh -C > > Apparently, ssh is managing to very significantly compress something > that tiger is missing. > > One anomaly that may be significant is the image size. > Size: 1366 x 1366 > > If I go fullscreen I get the full image height within my 1024 x 768 > client screen but with a large black area below that I can scroll to. So > for some reason the server is transmitting a large square rather than > the true desktop image. > > Can you suggest any reason for that ?
Maybe SSh is coalescing data when you enable compression, which may have a similar effect to increasing the deferred update timer. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Tigervnc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tigervnc-users
