xrfbviewer 0.0.2 (was / is still: Zlib integration)

Jonathan Morton chromi "at" cyberspace.org
Wed, 07 Jun 2000 18:33:09 +0000

>I've adapted Warren Toomey's protocol changes, see:

It appears to me that Warren's changes are not backwards compatible - as
his site mentions, if the server doesn't support his protocol and the
client requests it, the connection will probably be closed with an "unknown
message number: 10" error.

A backwards-compatible method might be to extend the list of encodings
available - to quote from page 15 of the RFB spec:

--- start quote ---
5.2.3 SetEncodings
Sets the encoding types in which pixel data can be sent by the server. The
order of the encoding types given in this message is a hint by the client
as to its preference (the first encoding specified being most preferred).
The server may or may not choose to make use of this hint. Pixel data may
always be sent in raw encoding even if not specified explicitly here.
No. of bytes Type [Value] Description
1 CARD8 2 message-type
1 padding
2 CARD16 number-of-encodings
	followed by number-of-encodings repetitions of the following:
No. of bytes Type [Value] Description
4 CARD32 encoding-type
	0 raw encoding
	1 copy rectangle encoding
	2 RRE encoding
	4 CoRRE encoding
	5 hextile encoding
--- end quote ---

The encoding-type value is 32-bit, and only the range [0..5] is currently
used by the specification - there is PLENTY of room here to insert a Zlib
encoding type.  Plus, if the server doesn't understand it, it should just
ignore it rather than breaking the connection - a good result.  Personally,
I suggest using number 26 for Zlib - Z being the 26th letter of the
alphabet...  or maybe the ASCII code for 'Z', which is 90.

I'm pretty sure one of the earlier implementations used this method too,
but I can't remember where it is.  If any implementations of it are still
floating around, and they appear sane, it might be a good idea to use that
protocol all-round, to avoid breaking them.

If we can't find the older version, then a new one shouldn't be too hard to
rustle up.  Something along the lines of either of the following:

<1> Zlib-wrapped Updates
Each rectangle sent as "Zlib encoding" itself contains one or more
FrameBufferUpdates which can use any of the "conventional" encoding types,
except of course Zlib itself.  CopyRect is unlikely to be suitable for
compression, being very small already - this would most probably be sent by

<2> Zlib-compressed Raw Data
Each rectangle sent as "Zlib encoding" is simply the X-by-Y raw data (as
would be sent by the raw encoding type) compressed by the Zlib routine.

The efficiency of both <1> and <2> would have to be found by experiment,
both for CPU efficiency and network bandwidth use.  Note that the Zlib
routines themselves consume a respectable amount of CPU time, so initial
encoding using the HexTile or CoRRE routines (using method <1>) may reduce
the load on the server and/or client CPUs while maintaining roughly
equivalent compression ratios.  OTOH, <2> is probably easier to implement
than <1>.

As a side note, once we can all decide on a Zlib-enabled protocol, perhaps
we should bump the version number on clients/servers that support it?  The
RFB 3.3 spec notes that changes in the minor-version number can be regarded
as benign, as would be the case given my suggested method of implementation
- so maybe RFB 3.4 is approaching...  If anyone has a serious objection to
this, please let us know.  :)  The 3.4 spec would be exactly the same as
the current 3.3, except that the encoding-type number and the precise
format for Zlib compression would be specified (in whatever form we
eventually decide).  As in 3.3, implementation of any encoding type apart
from Raw (this includes Zlib) in a specific server or client, is optional.
Eg. the Mac server currently does not implement RRE, CoRRE or CopyRect, but
it still complies with the 3.3 spec.

from:     Jonathan "Chromatix" Morton
mail:     chromi "at" cyberspace.org  (not for attachments)
uni-mail: j.d.morton "at" lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.
Contributing to the VNC Project - http://www.uk.research.att.com/vnc/
Macintosh VNCserver v3.3.2 beta2.3 now posted at:
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html