I'd like to announce a provisional new encoding: XZ.
The encoding is named, with permission, after the underlying library, XZ
Utils, and file format (.xz). The encoding is currently identical to ZRLE,
except the data is compressed into an XZ stream rather than a Zlib stream.
See http://tukaani.org/xz/ for more info regarding XZ Utils.
LZMA2, the algorithm used by XZ (and newer 7-zips), is superior to DEFLATE,
as used by Zlib, in terms of compression, especially for data as used by
VNC. The larger dictionary specifically provides significant compression
advantages, but of course this comes at the disadvantage of increased CPU
and RAM pressure. However even using faster parameters, the compression is
still similar to ZRLE if not outperforming it.
The pixel data is currently identical to that of ZRLE. I have tested out
various approaches over the past while, Paeth and delta encoding included,
but found either minimal or harmful effects on the compressed data size.
Perhaps surprisingly, I noticed a significant benefit during actual use by
including the rectangles in the compressed stream. I implemented this by
placing the low word of the number of rects in the update rect's y value
with the high word in the x value, and the low word of the compressed data
size in the rect's h value with the high word in the w value. All rectangles
in the update are then sent together, adjacent, within the compressed
stream. Once the rectangles are output, they are followed by the pixel data
for each rectangle in the same order.
I am not entirely convinced, so I am considering perhaps using this mode
only when enabled via a separate pseudoencoding. But considering each rect
includes a 12-byte overhead, and in my actual use testing I often had
updates with dozens of rectangles, lots of that rectangle overhead is
eliminated. Additionally this also means that the stream does not need to be
flushed for synchronization as often.
The LZMA2 stream's compression parameters, as implemented by XZ Utils,
required some tweaks for optimal performance. Obviously checksums are
disabled, and the hash chain method of matching patterns is used over the
usual btree method. Other parameters were tweaked but I am still in the
midst of running various tests on common streams to see how they effect
different pixel formats and usage scenarios. The dictionary size can vary
significantly, but I settled on 4 megabytes for 'average' use which did not
press resources too badly even on older computers. Of course any parameter
can be used by the server, which the client will respect, due to the
parameters being encoded within the XZ stream. This will allow it to be
implemented and restricted on more limited systems.
Using my 'average' settings versus ZRLE on Zlib's maximum settings show an
obvious different in CPU and RAM usage. However XZ encoding usually uses one
half to two thirds of the bandwidth compared to ZRLE. The most significant
improvements are psychological, however, since previously-displayed parts of
the screen may still have lots of patterns still in the dictionary. Flipping
among several windows is subjectively much more responsive than any other
encoding. Of course on a LAN it will probably be subjectively slower due to
CPU/RAM becoming the bottleneck rather than the network speed.
I am currently using the encoding number 18 (after ZYWRLE) and possibly 19
(for XZYW, since the code is similar enough that it is already working,
though I am not sure how much demand there really is for that since I
personally prefer the lossless encodings). I do not believe there are any
conflicts, but I would like to know so it can be modified.
My current implementation is built into UltraVNC, but the rdr and underlying
code is similar enough to most other implementations that porting it should
not be too much of an issue, especially if ZRLE is already implemented. I
intend to release the UltraVNC code shortly after considering feedback from
the community.
Any comments, questions, or general feedback is appreciated.
--
- Adam D. Walling
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
