Greg Breland's message about how TightVNC could perform worse than VNC
got me thinking...
It would be nice if TightVNC (and VNC in general, for that matter),
could have a "best" encoding option. Assuming that you can get some
round-trip timing information, then you could dynamically determine if
tight compression (for example) would be faster than hextile, based on
network latencies and CPU speed.
A simpler algorithm that doesn't need to know about the
characteristics of the encodings could simply dynamically try each of
the encodings and then stabilize on the best one. Could this be done
quickly? (And maybe later re-calibrate if the transfer throughput
changes a lot.)
A simple "determine best" encoding checkbox would disable the other
encoding choices. This would also be good for the clueless (like me)
who really don't know what the differences between the encodings are.
David
_________________________________________________________________________
David Coppit - Ph.D. Candidate [EMAIL PROTECTED]
The University of Virginia http://coppit.org/
"Yes," said Piglet, "Rabbit has Brain." There was a long silence.
"I suppose," said Pooh, "that that's why he never understands anything."
---------------------------------------------------------------------
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
---------------------------------------------------------------------
