>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.
ChromiVNC already determines the "best" encoder to use on a
per-update basis, by observing the compression ratio each encoding
produces for the data in question. However, it doesn't yet take CPU
speed (at either end) or network latency into account - it relies on
the user knowing enough to disable undesirable or superfluous codecs
at the viewer end.
--
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
website: http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline: The key to knowledge is not to rely on people to teach you it.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
