Release of new ``tight'' encoding available.

Const Kaplinsky const "at"
Sun, 27 Aug 2000 06:43:43 +0000

>>>>> "WBB" == W Brian Blevins <brian "at"> writes:

>> I'm glad to announce that I've finished main part of my VNC
>> compression project. All the source code and some comparison
>> results are available from the project homepage:

WBB> Great to see you are making good progress on your project. The
WBB> initial numbers look interesting. What applications are you
WBB> primarily testing against? We have found that results vary
WBB> considerably among desktop/window managers and various
WBB> applications. Often the specific environment in use brings out
WBB> the strengths/weaknesses of any given approach/encoding.

You are right -- results vary among different desktop contents. The
current version of the tight encoding is particularly good on screen
areas with small number of colors (most screen updates I've
encountered in different VNC sessions use less than 256 colors,
typically 1-5 colors per rectangle). On such rectangles tight encoding
is much better than pure zlib -- the algorithm I have implemented
represent these rectangles with indexed colors before compression (1
bits per pixel for 2-color images, 8 bits per pixel for 3..256 colors
per rectangle). But when color depth is 8, then maximum palette size I
use is 2 and therefore compression ratios in BGR233 mode is not much
better than zlib compression (usually 5-10% according to my practice).

Anyway, I've tried to design new encoding such way that it should work
better than zlib in most situations. Here is a brief explanation why
it's possible and how it is implemented:

  1. The algorithm includes pure zlib compression as one of
     subencodings (it is currently used for screen updates when a
     number of colors exceeds 256 or if a rectangle size is too small
     for using palette). I.e., it's possible to encode screen updates
     with pure zlib in tight encoding. And when it's not likely that
     some rectangle can be compressed much better, then pure zlib is
     used for coding such rectangle. But there is one situation when
     'pure zlib' in tight encoding differs from zlib encoding: 24-bit
     colors are represented by 24-bit samples instead of 32-bit ones
     before the compression stage.

  2. Up to four independent zlib streams can be used by tight encoder.
     It tries to compress different sorts of data in different zlib
     streams. This gives two benefits. First, effective size of
     dictionary increases up to four times (zlib uses only 32K data
     for its dictionary). Second, each compression stream represent a
     data set which is statistically more homogeneous and more
     suitable for compression).

Also, the tight encoder is usually faster than zlib in situations
where it gives stronger compression. But when compression ratios are
very close between tight and zlib (this situation shoud be rare),
compression speed of the tight encoder may get a bit slower compared
with pure zlib compression. But it currently cannot get much slower --
I believe that is about one percent or so in the worst case. And there
are several places in code where I'm still able to improve compression
speed further.

Now a little about drawbacks. The encoding itself as it has been
designed is very flexible. But current implementation does not use all
possibilities to improve compression. First of all, better results can
be achieved if the encoder (server side) could divide rectangles into
subrectangles depending on their contents. But current design of VNC
server code makes this somewhat problematic. So it will take a little
more time for me to implement better algorithms for splitting

And there is one more point for improvement. Tight encoding design
includes simple filter to improve compression for still images and
gradient-filled screen areas. I've tested this filter implementation
on the KDE wallpapers set: it improves compression ratios about 30-40%
on most files and compression is even better (and faster) than PNG
compression (of course, I don't try to compare file sizes with
original JPEGs). Although this filter is implemented on the client
side, current version of tight encoder does not produce framebuffer
rectangles coded in such way. There are two reasons for that: it's not
always simple to determine if the filter should be used or not
(compression ratios decrease if such filter is used on improper image)
and its implementation can be slow when color depth is not 24 (but
most widely used color depth for VNC is 16).

WBB> What encoding number did you use? We would like to avoid using
WBB> the same value in the future. Here is a list of the values in use
WBB> that I know of:

WBB> RFB Encodings Value Description 0 Raw 1 CopyRect 2 RRE (Rise and
WBB> Run length) 3 <unknown> 4 CoRRE (Compressed RRE) 5 Hextile 6 Zlib
WBB> (over raw)

WBB> What values are missing from this list? I would like to hear
WBB> about any other values in use. For one thing, I would really like
WBB> to update our source code to at least have all the values
WBB> declared in it (some implementations would be nice too). That
WBB> way, we can avoid conflicts with other developers.

I've used 7 as the number for the tight encoding.

By the way, if you are interested in integrating this encoding into
the TridiaVNC CVS tree, just let me know. In that case I'll prepare a
diff against CVS tree at, when new release of tight
encoder will be ready.

With Best Wishes,
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: