Skip to main content.

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
Auto scaling
Use DSM Plugin
Proxy/Repeater
Save connection settings as default

Further viewer configuration can be done when pressing the Options button.
Viewer connection options

Format and Encoding
See Encodings section below.
Mouse buttons
Mouse cursor
Display
Miscellaneous

Encodings

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.

Raw
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.
CopyRect
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.
RRE
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 subrectangles and color for each. This is an efficient encoding for large blocks of constant color.
CoRRE
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.
Hextile
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
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.
Tight
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).
Ultra
...