:: [EMAIL PROTECTED] (Wayne Throop) :: For both tightVNC and VNCclassic, the server negotiates with each :: viewer how encoding is done;
: Morrison Davis <[EMAIL PROTECTED]> : So, I've been trying to figure what are the best options to run with : the viewer to get the best performance. I have tightVNC server : running on my Office machine, from what you are saying no options at : are are best, that the server will negotiate the best options with the : client? Sadly, no. The negotiation is purely based on the encodings the participants know how to do, and the command line options that limit their choices. Specifically, no attempt is made (as far as I know) to measure latency or bandwidth and adjust the encoding on the fly; so if you really want to tailor things and squeeze the last bit of performance out, you'll have to do things like set the -compresslevel, -quality and -encodings. So for example, if your latency is farily long and you have low bandwidth, you would probably want to set -compresslevel to 9, to get things squashed into as small a bunch of bits as possible, even at the expense of more time thinking how to do it. But if both server and viewer were on the same LAN segment, you're better off saying -compresslevel 0, or even -encodings "copyrect hextile" or some such. Which will set up the connection to just blast the bits out and not waste time trying to be economical of bandwidth. Further, if you have lots of graphical images, you might want to allow tight encoding and set -quality to a lower number, if the number of bits to encode those complicated bits of the screen seemed to be the bottleneck slowing things down. So. To sum up, I wasn't trying to say that tightVNC's Xvnc and vncserver would automatically figure out the best configuration. I only meant that you didn't need to run VNCclassic's Xvnc to avoid tight encoding costs. You can restrict what tightVNC's vncviewer will allow as an encoding method for a given connection, without having to run a viewer or server which isn't even *capable* of tight encoding in order to avoid these overheads. As for me, I've found that the performance of the default options works well enough for me on both LAN and over WAN, so I don't spend much time tinkering. But then, I have both CPU horsepower and broadband WAN, so I'm not likely to need to tinker unless I need to use dialup someday on an image-intensive application or some such. The real reason I switched to tightVNC (even though it did speed up my remote access a bit), was to get local cursor handling. That's a neat feature that makes it worth switching to tightVNC for all uses, all by itself. (Even if I have noticed a few glitches in the cursor handling for windows apps... even so, it's worth it.) Wayne Throop [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
