Features/VNC Tight PNG

Tight PNG Specification

What ?

Introduce a new encoding: VNC_ENCODING_TIGHT_PNG (-260) and a new tight filter VNC_TIGHT_PNG (0x0A).

Tight PNG is a deviation of the original Tight encoding.

When the client indicates support for the Tight PNG encoding, the server will use Tight, but will always send encoding pixels using PNG instead of basic compression and indexed tight filters. This means the client does not have to handle raw zlib data.

If the client indicates JPEG support by sending a JPEG quality pseudo-encoding, then the server can send JPEG, because PNG will only replace the basic compression type used in normal tight.

This encoding was introduced to speed up HTML5 based VNC clients like noVNC [1], but can also be used on devices like iPhone where PNG can be rendered in hardware.

RFB Changes

Add a new encoding VNC_ENCODING_TIGHT_PNG (-260).

Tight changes

Add a new PNG filter (0x0A). This filter behaves exactly like the jpeg filter, except that the data is sent in PNG instead of JPEG.

++ b/ui/vnc-enc-tight.h
@@ -42,8 +42,9 @@
  *   bit 3:    if 1, then compression stream 3 should be reset;
  *   bits 7-4: if 1000 (0x08), then the compression type is "fill",
  *             if 1001 (0x09), then the compression type is "jpeg",
+ *             if 1010 (0x0A), then the compression type is "png",
  *             if 0xxx, then the compression type is "basic",
- *             values greater than 1001 are not valid.
+ *             values greater than 1010 are not valid.
  *
  * If the compression type is "basic", then bits 6..4 of the
  * compression control byte (those xxx in 0xxx) specify the following:
@@ -53,17 +54,17 @@
  *   bit 6:     if 1, then a "filter id" byte is following this byte.
  *
  *-- The data that follows after the compression control byte described
- * above depends on the compression type ("fill", "jpeg" or "basic").
+ * above depends on the compression type ("fill", "jpeg", "png" or "basic").
  *
  *-- If the compression type is "fill", then the only pixel value follows, in
  * client pixel format (see NOTE 1). This value applies to all pixels of the
  * rectangle.
  *
- *-- If the compression type is "jpeg", the following data stream looks like
- * this:
+ *-- If the compression type is "jpeg" or "png", the following data stream
+ * looks like this:
  *
  *   1..3 bytes:  data size (N) in compact representation;
- *   N bytes:     JPEG image.
+ *   N bytes:     JPEG or PNG image.
  *
  * Data size is compactly represented in one, two or three bytes, according
  * to the following scheme:
@@ -144,7 +145,7 @@
  *-- NOTE 2. The decoder must reset compression streams' states before
  * decoding the rectangle, if some of bits 0,1,2,3 in the compression control
  * byte are set to 1. Note that the decoder must reset zlib streams even if
- * the compression type is "fill" or "jpeg".
+ * the compression type is "fill", "jpeg" or "png".
  *
  *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only
  * when bits-per-pixel value is either 16 or 32, not 8.