Smart/dynamic determination of encoding type?

Jonathan Morton chromi "at"
Thu, 16 Aug 2001 11:41:02 +0000

>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:     chromi "at"  (not for attachments)
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 majordomo "at"
See also: