X11vnc Vs Tigervnc
Mitchell ondemand 2015 1q torrent. TigerVNC was originally based on the (never-released) VNC 4 branch ofTightVNC. More informationregarding the motivation for creating this project can be found in theprojectannouncement.
The latest release of TigerVNC can be downloaded from ourGitHub releasepage. Besides the source code we also provide self-contained binariesfor 64-bit and 32-bit Linux, installers for 64-bit and 32-bit Windows anda universal binary for Intel-based Macs. We also try to provide packagesfor various distributions when we easily can.
Pre-release builds of the experimental next-generation code can befound here.
- X0tigervncserver is a TigerVNC Server which makes any X display remotely accessible via VNC, TigerVNC or compatible viewers. Unlike Xvnc(1), it does not create a virtual display. Instead, it just shares an existing X server (typically, that one connected to the physical screen).
- Hi guys, is there any difference between performance between x11 vnc vs tight vnc.
- Yum install x11vnc-0.9.3-1.el5.rf.i386.rpm. Start the x11vnc process on the host you want the vnc-client to connect to. Please take a long look at the possible options from the x11vnc website. A very simple/insecure example for a trusted network setup (local network or VPN) is to have the user with the GUI console issue the command.
TigerVNC provides the levels of performance necessary to run 3D and video applications, and it attempts to maintain a common look and feel and re-use components, where possible, across the various platforms that it supports. TigerVNC also provides extensions for advanced authentication methods and TLS encryption. I like the toggles for x11vnc, having a wireframe mode, which doesn't seem to be a thing for Xvnc, but I also can't seem to get x11vnc to do fullscreen on dual monitors at 3200x1200, setting -geometry 3200x1200 doesn't work properly, the VM i'm connecting to only goes up to 2560 with this method.but if I connect with a Xvnc wrapper at.
TigerVNC is also provided with many distributions, such asFedora,OpenSUSE,FreeBSD,Arch Linux,Red Hat Enterprise Linux andSUSE Linux Enterprise.
The project has three mailing lists:
Moderated announcement list for new releases and other important news.
X11vnc Vs Vnc Server
Support and general discussion list for users of TigerVNC. Please use this list for bug reports.
Discussion list for TigerVNC developers. This list can be used for patch submissions and other development ideas.
The man pages for the different programs are available here in HTML form: Nfs most wanted 2005 full hd.
This documentation is for the Unix programs but is mostly relevant forthe equivalent Windows programs as well.
If there is an issue you'd really like to get fixed, or if you're aprogrammer that could use some extra cash, head over toBountysourcefor information on how to trade bugs and features for the almighty buck.You can also make a general donation, which we (the TigerVNC admins)can distribute as bounties on existing issues.
A community maintained version of the VNC/RFB specification is maintained by the rfbproto project.
Assorted documentation about TigerVNC and development can be found inthe developmentsection of the wiki.
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.
In 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 |
X11vnc Vs Tigervnc 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). |
More information on testing
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. Service tool v 4905 google drive.
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 distilled 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. :-)
| Last modified: Fri Jan 12 04:32:09 KRAT 2001 Constantin Kaplinsky:e-mail. |