UltraVnc Viewer Configuration

There are a lot of options that can be configured from the viewer side. Viewer quick options

Quick options

The quick options relate to the following configuration settings:
Auto Quick Option: Auto
LAN Quick Option: LAN
Medium Quick Option: Medium
Modem Quick Option: Modem
Slow Quick Option: Slow
Ultra Quick Option: Ultra

View Only
No keyboard or mouse events are sent from the viewer to the server. The server screen can only be viewed, but not controlled.
Auto scaling
The viewer window is automatically scaled to fit the size of your local screen.
Use DSM Plugin
Choose a DSM (Data Stream Modification) Plugin and configure it.
To use an encryption plugin, for instance, check this option and select the plugin in the combo box. The plugin file must be in the same directory than the vncviewer.exe program. And of course, the same plugin must be used by the UltraVNC server you connect to.
Specify the repeater address here.
Save connection settings as default
If checked, the current settings are saved as default options in a configuration file. So next time you run the viewer, you don't have to reselect all your favorite settings.
Further viewer configuration can be done when pressing the Options button.
Viewer connection options
Format and Encoding
See Encodings section below.
Note: Grey colors only works with 32 bits color screen resolution. 16/24 bits color resolutions just don't work with grey colors.
Mouse buttons
Mouse cursor


This section (except Ultra encoding) is taken from TightVNC's vncviewer man page.

The server supplies information in whatever format is desired by the client, in order to make the client as easy as possible to implement. If the client represents itself as able to use multiple formats, the server will choose one.

Pixel format refers to the representation of an individual pixel. The most common formats are 24 and 16 bit "true-color" values, and 8-bit "color map" representations, where an arbitrary map converts the color number to RGB values.

Encoding refers to how a rectangle of pixels are sent (all pixel information in VNC is sent as rectangles). All rectangles come with a header giving the location and size of the rectangle and an encoding type used by the data which follows. These types are listed below.

The raw encoding simply sends width*height pixel values. All clients are required to support this encoding type. Raw is also the fastest when the server and viewer are on the same machine, as the connection speed is essentially infinite and raw encoding minimizes processing time.
The Copy Rectangle encoding is efficient when something is being moved; the only data sent is the location of a rectangle from which data should be copied to the current location. Copyrect could also be used to efficiently transmit a repeated pattern.
The Rise-and-Run-length-Encoding is basically a 2D version of run-length encoding (RLE). In this encoding, a sequence of identical pixels are compressed to a single value and repeat count. In VNC, this is implemented with a background color, and then specifications of an arbitrary number of sub rectangles and color for each. This is an efficient encoding for large blocks of constant color.
This is a minor variation on RRE, using a maximum of 255x255 pixel rectangles. This allows for single-byte values to be used, reducing packet size. This is in general more efficient, because the savings from sending 1-byte values generally outweighs the losses from the (relatively rare) cases where very large regions are painted the same color.
Here, rectangles are split up in to 16x16 tiles, which are sent in a predetermined order. The data within the tiles is sent either raw or as a variant on RRE. Hextile encoding is usually the best choice for using in high-speed network environments (e.g. Ethernet local-area networks).
Zlib is a very simple encoding that uses zlib library to compress raw pixel data. This encoding achieves good compression, but consumes a lot of CPU time. Support for this encoding is provided for compatibility with VNC servers that might not understand Tight encoding which is more efficient than Zlib in nearly all real-life situations.
Like Zlib encoding, Tight encoding uses zlib library to compress the pixel data, but it pre-processes data to maximize compression ratios, and to minimize CPU usage on compression. Also, JPEG compression may be used to encode color-rich screen areas (see the description of -quality and -nojpeg options above). Tight encoding is usually the best choice for low-bandwidth network environments (e.g. slow modem connections).
Experimental, Ultra encoding provides real time performance over a LAN by utilizing LZO compression. LZO is a data compression scheme which is suitable for data de-/compression in real-time. This means it favors speed over compression ratio.