Where Xvnc contains its own X server, x11vnc does not. It's a VNC server that integrates with an already running X server, Xvnc, or Xvfb. It does have the unique feature of being able to connect to things that have a framebuffer. X11vnc keeps a copy of the X server's frame buffer in RAM. 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. X11vnc is a VNC server, it allows one to view remotely and interact with real X displays (i.e. A display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. While it is not developed any longer by its original author Karl Runge, LibVNC and the GitHub community have taken over the development. X11vnc does not create an extra display (or X desktop) for remote control.

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.

Use fail2ban to stop people brute forcing it. Put it on a non-standard port for bonus points. Then from Windows (Putty, a SSH client) you connect to Ubuntu forwarding the Ubuntu's local VNC traffic over the SSH connection to a Windows-local port. Then Putty tell's Ubuntu to run x11vnc. Installing VNC Server. To install the TigerVNC server, issue the following command as root: # yum.

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

	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Test session 1: bugzilla-16.rfb (bzip2-compressed: 439,285 bytes)	Encodings
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).

	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Test session 2: compilation-16.rfb (bzip2-compressed: 252,800 bytes)	Encodings
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).

	Raw	Hextile	Zlib	Tight-1.0	Tight-1.1L	Tight-1.1
Test session 3: bars-16.rfb (bzip2-compressed: 4,746,651 bytes)	Encodings
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

X11vnc Vs Tigervnc