summaryrefslogtreecommitdiff
path: root/ui/vnc-enc-tight.h
diff options
context:
space:
mode:
authorCorentin Chary <corentincj@iksaif.net>2010-07-07 20:57:56 +0200
committerAnthony Liguori <aliguori@us.ibm.com>2010-07-26 17:36:14 -0500
commitefe556adb75a20ab71f3e5b1c5b19bf045e7953f (patch)
tree1ad2906fd0fd77b5458ac2592a64c4fe4b8d301e /ui/vnc-enc-tight.h
parentd9c18c24b9c80cae1a6882976c9247a99444cf52 (diff)
downloadqemu-efe556adb75a20ab71f3e5b1c5b19bf045e7953f.tar.gz
vnc: tight add PNG encoding
Introduce a new encoding: VNC_ENCODING_TIGHT_PNG [1] (-269) with a new tight filter VNC_TIGHT_PNG (0x0A). When the client tells it supports the Tight PNG encoding, the server will use tight, but will always send encoding pixels using PNG instead of zlib. If the client also told it support JPEG, then the server can send JPEG, because PNG will only be used in the cases zlib was used in normal tight. This encoding was introduced to speed up HTML5 based VNC clients like noVNC [2], but can also be used on devices like iPhone where PNG can be rendered in hardware. [1] http://wiki.qemu.org/VNC_Tight_PNG [2] http://github.com/kanaka/noVNC/ Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'ui/vnc-enc-tight.h')
-rw-r--r--ui/vnc-enc-tight.h16
1 files changed, 9 insertions, 7 deletions
diff --git a/ui/vnc-enc-tight.h b/ui/vnc-enc-tight.h
index 9b0910c79a..a3add788e2 100644
--- a/ui/vnc-enc-tight.h
+++ 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.
@@ -158,7 +159,8 @@
#define VNC_TIGHT_EXPLICIT_FILTER 0x04
#define VNC_TIGHT_FILL 0x08
#define VNC_TIGHT_JPEG 0x09
-#define VNC_TIGHT_MAX_SUBENCODING 0x09
+#define VNC_TIGHT_PNG 0x0A
+#define VNC_TIGHT_MAX_SUBENCODING 0x0A
/* Filters to improve compression efficiency */
#define VNC_TIGHT_FILTER_COPY 0x00