I once did a survey of this involving several of the major implementations,
but can't really remember if I checked both little and big endian servers.
I for sure did check with both little and big endian on the wire though.
Signed-off-by: Peter Rosin <p...@lysator.liu.se>
Cheers,
Peter
diff --git a/rfbproto.rst b/rfbproto.rst
index 896fb8b..d7769db 100644
--- a/rfbproto.rst
+++ b/rfbproto.rst
@@ -1484,6 +1484,13 @@ 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``.
+Note that for the corner case where *bits-per-pixel* is 32 and *depth*
+is 16 or less (this is a corner case, since the client is **much**
+better off using 16 or even 8 *bits-per-pixels*) a ``CPIXEL`` is still
+3 bytes long. By convention, the three least significant bytes are used
+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
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
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
