On Thu, 08 Oct 2009 19:39:12 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
> Hi!
>
> I snarfed the TRLE description from the Internet draft.
> I then changed the ZRLE description to also match the
> Internet draft (TRLE is really very similar to ZRLE)
>
> Three patches to make it easier to review, commit in one
> go if you feel like it.
>
> I have taken care to keep our local changes to the ZRLE
> description.
>
This looks nice, but I'm thinking we might want to merge patch 1 and 2
as it shows how the bulk of the description is only moved from ZRLE to
TRLE (with the downside of the ZRLE introduction is removed and
readded).
It does highlight some changes in the wording though. Do we want these,
and if we do should they be in a separate commit?
From the intro:
+TRLE makes use of a new type ``CPIXEL`` (compressed pixel). This is the
+same as a ``PIXEL`` for the agreed pixel format, except as a special
+case, it uses a more compact format if *true-colour-flag* is non-zero,
+*bits-per-pixel* is 32, *depth* is 24 or less and all of the bits
+making up the red, green and blue intensities fit in either the least
+significant 3 bytes or the most significant 3 bytes. In this case, a
+``CPIXEL`` is only 3 bytes long, and contains the least significant or
+the most significant 3 bytes as appropriate. *bytesPerCPixel* is the
+number of bytes in a ``CPIXEL``.
-
-ZRLE makes use of a new type ``CPIXEL`` (compressed pixel). This is the
-same as a ``PIXEL`` for the agreed pixel format, except where
-*true-colour-flag* is non-zero, *bits-per-pixel* is 32, *depth* is 24
-or less and all of the bits making up the red, green and blue
-intensities fit in either the least significant 3 bytes or the most
-significant 3 bytes. In this case a ``CPIXEL`` is only 3 bytes long,
-and contains the least significant or the most significant 3 bytes as
-appropriate. *bytesPerCPixel* is the number of bytes in a ``CPIXEL``.
-
And from the subencoding descriptions:
@@ -2270,13 +2256,19 @@
when both the three least and the three most significant bytes would
cover the used bits.
-Each tile begins with a *subencoding* type byte. The top bit of this
+Each tile begins with a subencoding type byte. The top bit of this
byte is set if the tile has been run-length encoded, clear otherwise.
The bottom seven bits indicate the size of the palette used: zero means
-no palette, one means that the tile is of a single colour, 2 to 127
-indicate a palette of that size. The possible values of *subencoding*
-are:
+no palette, one means that the tile is of a single color, and 2 to 127
+indicate a palette of that size. The special values 129 and 127
+indicate that the palette is to be reused from the previous tile, with
+and without RLE respectively.
+Note: in this discussion, the div(a,b) function means the result of
+dividing a/b truncated to an integer.
+
+The possible values of subencoding are:
+
0
Raw pixel data. *width* * *height* pixel values follow (where width
and height are the width and height of the tile):
@@ -2298,16 +2290,17 @@
========================== ============= ==========================
2 to 16
- Packed palette types. Followed by the palette, consisting of
- *paletteSize* (=*subencoding*) pixel values. Then the packed pixels
- follow, each pixel represented as a bit field yielding an index
- into the palette (0 meaning the first palette entry). For
- *paletteSize* 2, a 1-bit field is used, for *paletteSize* 3 or 4 a
- 2-bit field is used and for *paletteSize* from 5 to 16 a 4-bit
- field is used. The bit fields are packed into bytes, the most
- significant bits representing the leftmost pixel (i.e. big endian).
- For tiles not a multiple of 8, 4 or 2 pixels wide (as appropriate),
- padding bits are used to align each row to an exact number of bytes.
+ Packed palette types. The *paletteSize* is the value of the
+ *subencoding*, which is followed by the palette, consisting of
+ *paletteSize* pixel values. The packed pixels follow, with each
+ pixel represented as a bit field yielding a 0-based index into the
+ palette. For *paletteSize* 2, a 1-bit field is used, for
+ *paletteSize* 3 or 4 a 2-bit field is used, and for *paletteSize*
+ from 5 to 16 a 4-bit field is used. The bit fields are packed into
+ bytes, with the most significant bits representing the leftmost
+ pixel (i.e. big endian). For tiles not a multiple of 8, 4 or 2
+ pixels wide (as appropriate), padding bits are used to align each
+ row to an exact number of bytes.
================================= ================== ==============
No. of bytes Type Description
@@ -2317,14 +2310,19 @@
================================= ================== ==============
where *m* is the number of bytes representing the packed pixels.
- For *paletteSize* of 2 this is floor((*width* + 7) / 8) * *height*,
- for *paletteSize* of 3 or 4 this is
- floor((*width* + 3) / 4) * *height*, for *paletteSize* of 5 to 16
- this is floor((*width* + 1) / 2) * *height*.
+ For *paletteSize* of 2 this is div(*width* + 7, 8) * *height*, for
+ *paletteSize* of 3 or 4 this is div(*width* + 3, 4) * *height*, for
+ *paletteSize* of 5 to 16 this is div(*width* + 1, 2) * *height*.
-17 to 127
- Unused (no advantage over palette RLE).
+17 to 126
+ Unused. (Packed palettes of these sizes would offer no advantage
+ over palette RLE).
+127
+ Packed palette with the palette reused from the previous tile. The
+ subencoding byte is followed by the packed pixels as described
+ above for packed palette types.
+
128
Plain RLE. Consists of a number of runs, repeated until the tile is
done. Runs may continue from the end of one row to the beginning of
@@ -2344,10 +2342,12 @@
1 ``U8`` (*runLength* - 1) % 255
=================== =============== ======= =======================
- Where *r* is floor((*runLength* - 1) / 255).
+ Where *r* is div(*runLength* - 1, 255).
129
- Unused.
+ Palette RLE with the palette reused from the previous tile.
+ Followed by a number of runs, repeated until the tile is done, as
+ described below for 130 to 255.
130 to 255
Palette RLE. Followed by the palette, consisting of
@@ -2359,9 +2359,9 @@
*paletteSize* * *bytesPerCPixel* ``CPIXEL`` array *palette*
================================= ================== ==============
- Then as with plain RLE, consists of a number of runs, repeated
- until the tile is done. A run of length one is represented simply
- by a palette index:
+ Following the palette is, as with plain RLE, of a number of runs,
+ repeated until the tile is done. A run of length one is
+ represented simply by a palette index:
================================= ================== ==============
No. of bytes Type Description
@@ -2381,8 +2381,38 @@
1 ``U8`` (*runLength* - 1) % 255
=================== =============== ======= =======================
- Where *r* is floor((*runLength* - 1) / 255).
+ Where *r* is div(*runLength* - 1, 255).
Rgds
--
Pierre Ossman OpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
