TightVNC: Comparison Results

Site Contents: Main Page Download Area Encoding Comparisons What's New Change Logs: Unix, Win32, Java Documentation

Useful Links: Primary TightVNC Site TightVNC at SourceForge.net TightVNC Mailing List TightVNC at FreshMeat.net TridiaVNC Developers Official VNC Homepage

Help the project -- donate $10 to support TightVNC development!

Warning

Please note that the comparisons presented below correspond to the 1.1 version of the Tight Encoder and do not reflect major enhancements introduced in TightVNC 1.2. Measuring performance and providing detailed comparisons is not always straightforward and takes time, but at current moment I prefer to concentrate on development instead of preparing accurate performance comparisons. The only thing I can say for sure is that TightVNC 1.2 significantly improves both bandwidth and CPU usage efficiency as compared to older versions of VNC Tight Encoder.

Preface

Here you can see how new Tight-1.1 encoder operates as compared to older Hextile and Zlib encoders. Zlib encoder was obtained from the TridiaVNC source archive for Unix. Results for older version of the Tight encoder are also shown here ("Tight-1.0" column). The "Tight-1.1L" abbreviation means Tight-1.1 encoder with new "gradient" filter turned off (this can be done with -lazytight Xvnc command-line option). Main competitor is Zlib encoder, and that is why improvements in compression ratio for the Tight-1.1 encoder against Zlib are emphasized using red color for text.

At the bottom of this page you can find more information on testing and other related issues. Note that all test sessions as well as complete source code for testing utility are freely available for everybody. But you should be aware that some of test sessions are huge downloads and they may reside behind a very slow Internet connection.

The results

Test session 1: bugzilla-16.rfb (bzip2-compressed: 439,285 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	32,729,254	1,590,721	652,572	518,112	499,140	499,140
Bandwidth savings, Tight-1.1 vs. others	98.47%	68.62%	23.51%	3.66%	-	-
Compression time, seconds	-	1.3	25.8	18.9	14.8	14.9

Description:	This is 16-bit-color test session, presenting operations in Netscape Navigator window on KDE desktop. Browser is showing Bugzilla Web site. Original session is available from the rfbproxy Web pages.
Explanations:	Test shows good compression performance achieved by the Tight Encoder on typical session where not many full-color areas can be found on the screen. Most improvement in both compression ratio and compression time is caused by replacing true-color RGB samples with indexed colors before compression. Due to the problem found in the Tight-1.0 encoder, the compression ratio achieved by Tight-1.1 (where the problem has been fixed) is a little better than for version 1.0 of the encoder. Compression time has been decreased for Tight-1.1 vs. Tight-1.0 due to speed optimizations in 1.1 release. Results for Tight-1.1L and Tight-1.1 do not differ because the latter encoder has not found any areas suitable for preprocessing with the "gradient" filter.
More details:	Here you can find original test results for this session, where you can see compressed data sizes separately for each rectangle of screen updates: bugzilla-16-logs.tar.bz2 (download size: 144,024 bytes).

Test session 2: compilation-16.rfb (bzip2-compressed: 252,800 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	111,178,662	2,788,259	1,836,495	476,738	454,748	454,748
Bandwidth savings, Tight-1.1 vs. others	99.59%	83.69%	75.24%	4.61%	-	-
Compression time, seconds	-	5.2	231.5	29.7	21.5	21.3

Description:	This 16-bit-color session shows Xvnc compilation process started in xterm window maximized to occupy almost full screen. The window manager is IceWM.
Explanations:	This test session is prepared in order to show Tight Encoder efficiency on compressing two-color (monochrome) screen areas. We see that compression ratio on such data may be four times (!) better than it stands for pure Zlib compression. Compression speed improvement is even more impressive: Tight encoder is about ten times faster on this session as compared to Zlib encoder. Also note raw data size: it's about 106 MBytes, and it's only 444 KBytes for Tight-1.1 encoding (compression ratio is 244.48). Such improvement in both compression ratio and speed is caused by replacing 16-bit true-color pixel values with 1-bit indices in 2-color palette. So the input stream size for final zlib compressor may be up to 16 times smaller. This allows zlib library to use its small (32K) dictionary much more efficiently. And compression speed is increased dramatically just because there is much less data to compress.
More details:	Original test results for this session: compilation-16-logs.tar.bz2 (download size: 12,392 bytes).

Test session 3: bars-16.rfb (bzip2-compressed: 4,746,651 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	32,880,890	11,812,296	3,632,612	3,852,823	3,482,707	3,191,666
Bandwidth savings, Tight-1.1 vs. others	90.29%	72.98%	12.14%	17.16%	8.36%	-
Compression time, seconds	-	2.6	74.7	62.6	45.8	52.3

Description:	16-bit test session demonstrating intensive use of full-color graphics. It's a WindowMaker desktop with wallpaper enabled. A photo image is opened in a Gimp window, then some manipulations are performed on that window.
Explanations:	This test basically shows two things: certain problems with Tight-1.0 encoder on full-color images and the efficiency of new "gradient" filter on suitable image data. You can see that Tight-1.0 compression ratio was worse than Zlib results and that compression is improved in version 1.1 even when "gradient" filtering is disabled. And enabling such filtering gives us about 8% of extra bandwidth savings while compression is a little slower.
More details:	Original test results for this session: bars-16-logs.tar.bz2 (download size: 122,352 bytes).

Test session 4: kde-hearts-16.rfb (bzip2-compressed: 3,130,374 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	22,901,336	13,711,535	2,011,507	2,381,792	1,787,521	1,788,952
Bandwidth savings, Tight-1.1 vs. others	92.19%	86.95%	11.06%	24.89%	-0.08%	-
Compression time, seconds	-	2.4	26.1	22.8	17.5	17.5

Description:	16-bit test session demonstrating intensive use of full-color graphics used as background for icons and text. It is KDE desktop with wallpaper (coloured_hearts.jpg) enabled. Several kfm windows with different background images are opened, some simple manipulations are performed on these windows.
Explanations:	Again, this test shows Tight-1.0 problems and Tight-1.1 enhancements. Tight-1.0 results are poor as compared to Zlib encoder, Tight-1.1 results are much better. This session contains much data that is "inconvenient" for the "gradient" filter. And you can see that enabling this filter increases compressed data size a bit. But the difference is negligible because the code detecting still-image areas prevents such filtering in most doubtful cases.
More details:	Original test results for this session: kde-hearts-16-logs.tar.bz2 (download size: 109,028 bytes).

Test session 5: freshmeat-8.rfb (bzip2-compressed: 1,716,336 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	107,621,635	4,779,238	2,635,469	2,345,674	2,265,923	2,265,923
Bandwidth savings, Tight-1.1 vs. others	97.89%	52.59%	14.02%	3.40%	-	-
Compression time, seconds	-	7.4	147.5	98.0	86.6	86.2

Description:	This 8-bit-color (BGR233) session shows real dial-up session when a person is fetching his mail, reading news at freshmeat.net, searching there an utility he need, downloading it etc.
Explanations:	This session presents a bit of real computer usage. The color depth is 8 bits and the difference in compression ratios between Zlib and Tight is not very impressive. That is because at such color depth there is really not much space for improvement. However, note that the compression speed is still much higher as compared to Zlib and 14% decrease in data size is also not too bad. Looking at the compressed data size, keep in mind that this session is long enough: it's about 8 minutes of continuous activity.
More details:	Original test results for this session: freshmeat-8-logs.tar.bz2 (download size: 785,370 bytes).

Test session 6: slashdot-24.rfb (bzip2-compressed: 3,073,017 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	271,717,540	8,716,348	4,487,303	3,348,609	3,297,038	3,297,038
Bandwidth savings, Tight-1.1 vs. others	98.79%	62.17%	26.53%	1.54%	-	-
Compression time, seconds	-	5.7	341.8	149.4	134.2	134.2

Description:	24-bit-color session showing a real dial-up session when a person is reading news at slashdot.org, generating a ChangeLog for CVS tree, editing it in XEmacs, fetching his mail and more. It's similar to the freshmeat-8 test session, but now color depth is 24 bits and there is more different types of activity seen on the screen. The session is about 6 minutes 30 seconds long.
Explanations:	The compression ratios are somewhat typical for real-world usage. The difference between Zlib and Tight efficiency is notable. Main reason is that many screen updates can be converted from true-color to indexed colors using palette with small number of colors. Another reason is that the tight compression is well-optimized for 24-bit sessions; it even converts 32-bit pixel values with one of bytes set to zero (as they are presented in RFB protocol) to 3-byte RGB samples.
More details:	Original test results for this session: slashdot-24-logs.tar.bz2 (download size: 415,219 bytes).

Test session 7: photos-24.rfb (bzip2-compressed: 8,187,724 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	25,569,676	16,781,057	10,657,746	9,830,852	9,966,649	6,130,479
Bandwidth savings, Tight-1.1 vs. others	76.02%	63.47%	42.48%	37.64%	38.49%	-
Compression time, seconds	-	1.6	24.1	14.6	14.1	35.3

Description:	Test session demonstrating intensive use of full-color graphics in 24-bit mode. It is IceWM desktop with photo image used as wallpaper. Another photo is viewed in a Gimp window.
Explanations:	The results show great improvement (about 40%) in compression ratio when the "gradient" filter is used on suitable data. When color depth is 24 bits, this filter can give greatest compression improvements. But you can see that the cost we pay for that is much slower compression. The second issue seen in results above is that the Tight-1.1L encoder operates a little worse than Tight-1.0 implementation. It's a rare situation, but it's possible. The reason is difference in algorithms used to split large screen areas into smaller sub-rectangles. The algorithm used in 1.1 version typically operates better, but that is not the point for all possible situations.
More details:	Original test results for this session: photos-24-logs.tar.bz2 (download size: 32,044 bytes).

Test session 8: kde-hearts-24.rfb (bzip2-compressed: 5,800,212 bytes)	Encodings
	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Data size in screen updates, bytes	36,152,860	20,052,400	2,066,224	2,242,507	1,744,684	1,790,153
Bandwidth savings, Tight-1.1 vs. others	95.05%	91.07%	13.36%	20.17%	-2.61%	-
Compression time, seconds	-	2.4	46.0	27.2	20.4	20.6

Description:	24-bit test session demonstrating intensive use of full-color graphics used as background for icons and text. The session is very similar to kde-hearts-16. It is the same KDE desktop with wallpaper enabled. Several kfm windows with different backgrounds are opened, some simple manipulations are performed on these windows.
Explanations:	The results are similar to those for the kde-hearts-16 session. It's clear that not every full-color image is a good candidate for the filtering algorithm implemented in the Tight-1.1 encoding even when color depth is 24 bits. Image type detection routine tries to prevent applying the filter when it thinks the data is not suitable for it, but this is not 100%-reliable, so we've got a little loss both is compression ratio and speed when the filtering is on.
More details:	Original test results for this session: kde-hearts-24-logs.tar.bz2 (download size: 86,154 bytes).

Test sessions

Test sessions were recorded with rfbproxy, a program which can sit between VNC server and client and is able to record all data received from the server into a local file. After a session is recorded, it can be played back for remote client with the same program. All tests were recorded under Linux using standard Xvnc 3.3.3r1 as VNC server. The only encoding scheme used in test sessions was "hextile" encoding. So you don't have to run VNC software with support for tight encoding if you wish to look at test session contents.

Note that the Unix version of vncviewer cannot be forced to use 16-bit or 32-bit (24-bit) pixel formats; it uses your default screen format as reported by the X server. It means you won't be able to look at 16-bit test sessions on 32-bit display and vice versa. So make sure you have set appropriate color depth for your X Window System installation before viewing a session with the Unix vncviewer. 8-bit sessions can be played back regardless of color depth (if there are enough colors), but you must use -bgr233 vncviewer option to view such sessions.

The testing

The testing has been performed on a Pentium-II machine (350MHz CPU, 512K CPU cache) with 64M RAM under GNU/Linux operating system (kernel-2.2.10-ac9, glibc-2.0.7 - yes, it's not very up-to-date).

First, saved test sessions were distiled using small fbs-dump.c utility. This utility removes control information from test sessions saved with rfbproxy, producing files containing only RFB messages received from the server (see RFB protocol specification). This makes message parsing much easier for testing utility.

Finally, specially written compare-encodings utility was used to produce comparison results. This utility reads hextile-encoded framebuffer updates from a file, decodes them, encodes each rectangle with a set of different encoders and dumps statistics to the standard output. Source files for encoders are included unmodified from the VNC distributions (not true for zlib, where I had to make a pair of changes to adapt it for the Xvnc-3.3.3r1, but these changes do not affect performance in any way). Note that compression speed is not reported by the testing utility. Timing results were obtained by running modified versions of the utility separately for each encoding. Be aware that the testing utility was not aimed to be comfortable at its usage. No help for options, no warranty, configuration via #define directives or via renaming source files, etc. It's probably for use by programmers only.

The last thing to say here: if you'll be lucky to record a session where the latest version of tight encoder shows poor performance as compared to pure zlib compression, please make that session available for me if possible. This will help me to make the encoder better and its users happier. :-)