Fw: tight encoding in realvnc?
Sun Jan 19 18:53:01 2003
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.
> Wez @ RealVNC Ltd. - http://www.realvnc.com
> Open Source VNC - Commercial Support & Development
--- end comment ---
----- Original Message -----
From: "James ''Wez'' Weatherall" <firstname.lastname@example.org>
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
> > 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