Fw: tight encoding in realvnc?

[Carl]

James sent me this.  I think it was meant for the group. If it was not, it
is still informative.  I'm putting his comment immetiately below.  BTW, what
I wrote was this: "How does TightVNC compare to RealVNC when dialing up, say
via a 56k line?"  I happen to use RealVNC.  I tried TightVNC but did not
like that with each re-boot, it nagged me for button clicks.

--- start comment ---
> You have missed out the encoding that VNC would actually use over a 56K
> line - ZRLE.  ZRLE performs at least as well as Tight over slow
> connections, and was introduced in VNC 3.3.4, which is why there's been
> no need to add the Tight encoding.
>
> VNC 3.3.4 and above will auto-select the encoding and colour depth of
> the connection based on the apparently available bandwidth.
>
> Cheers,
>
> --
> Wez @ RealVNC Ltd. - http://www.realvnc.com
> Open Source VNC - Commercial Support & Development
--- end comment ---

Carl

----- Original Message -----
From: "James ''Wez'' Weatherall" <jnw22@cam.ac.uk>
To: <fabbe@paniq.net>
Cc: <vnc-list@realvnc.com>
Sent: Sunday, January 19, 2003 9:55 AM
Subject: Re: tight encoding in realvnc?


> On Sun, 2003-01-19 at 01:26, Carl wrote:
>
> > > How does TightVNC compare to RealVNC when dialing up, say via a 56k
line?
> >
> > I have no real numbers to compare (I assume that the only measurable
> > quantity is the amount of data transferred with a particular encoding
> > for a particular screen), but the subjective impression is that the
> > 'tight' encoding performs 'better' over slow links than 'hextile',
> > 'corre', 'rre', 'copyrect', and, obviously, 'raw', that are provided
> > with RealVNC. 'tight' uses an optimized zlib compression scheme combined
> > with jpeg compression to achieve this.
>
> _______________________________________________
> VNC-List mailing list
> VNC-List@realvnc.com
> http://www.realvnc.com/mailman/listinfo/vnc-list