>>>>> "TAJ" == Todd A Jacobs <[EMAIL PROTECTED]> writes:
TAJ> I perform almost all of my VNC connections through an ssh
TAJ> tunnel, using compression-level 6. When I was looking over
TAJ> the performance statistics of the tight encoding patch, it
TAJ> occured to me that there might not be any benefit to using
TAJ> the new encoding over hextile when something else (in this
TAJ> case ssh) was doing the compression.
TAJ> Does tight encoding make any sense over a 128 Kbps ssh
TAJ> connection?
Surely, it should make sense. Compression ratios achieved by the tight
encoder are notably higher as compared to SSH (zlib) compression. The
second issue is that the tight encoder is typically much faster than
zlib over raw data. In your case, the best results could be achieved
if you will use tight+copyrect encodings and disable compression in
SSH.
If you use some kind of Unix on client side, then you also might like
the -tunnel vncviewer option supported in the tight encoder patch. It
can start SSH forwarding automatically on the vncviewer startup. For
example:
$ vncviewer -tunnel -encodings 'tight copyrect' some.remote.host:1
fwd connect from 127.0.0.1 to local port sshdfwd-5599
VNC server supports protocol version 3.3 (viewer 3.3)
Password:
VNC authentication succeeded
...
Finally, one more very useful option included in the latest tight
encoding patch for Unix (1.1p5 version) is "local cursor" feature
which dramatically improves performance. The only problem is that
Windows version of this feature is not ready yet and I don't see much
interest on this project at the Cosource.com pages:
https://www.cosource.com/cgi-bin/cos.pl/bid/info/99
--
With Best Wishes,
Constantin
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
