Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.
Den 2009-06-16 16:35 skrev Pierre Ossman: > On Tue, 16 Jun 2009 16:22:27 +0200 > Peter Rosin wrote: > >> So, again, I think all these deficiencies should be fixed in a followup >> commit (or commits)... >> > > Fair enough. Could you prepare those changes though so this isn't one > of those things that gets overlooked and forgotten? Ok, I'll make the series 6 patches long instead. Cheers, Peter -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.
On Tue, 16 Jun 2009 16:22:27 +0200 Peter Rosin wrote: > > So, again, I think all these deficiencies should be fixed in a followup > commit (or commits)... > Fair enough. Could you prepare those changes though so this isn't one of those things that gets overlooked and forgotten? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.
Den 2009-06-16 13:58 skrev Pierre Ossman: > On Thu, 11 Jun 2009 13:30:41 +0200 > Peter Rosin wrote: > >> +The least significant four bits of *compression-control* byte inform >> +the client which zlib compression streams should be reset before >> +decoding the rectangle. Each bit is independent and corresponds to a >> +separate zlib stream that should be reset: >> + >> +== >> +BitDescription >> +== >> +0 if 1: reset stream 0 >> +1 if 1: reset stream 1 >> +2 if 1: reset stream 2 >> +3 if 1: reset stream 3 >> +== > > I think the "if 1:" part is implied. :) Me too, but I wanted to first get the spec as written by Const (or whoever wrote it) into the document using as little modifications as possible, strange footnotes, missing references and all. We can improve the text in later commits. >> +One of three possible compression methods are supported in the Tight >> +encoding. These are **BasicCompression**, **FillCompression** and >> +**JpegCompression**. If the bit 7 (the most significant bit) of >> +*compression-control* byte is 0, then the compression type is >> +**BasicCompression**. In that case, bits 7-4 (the most significant four >> +bits) of *compression-control* should be interpreted as follows: >> + >> +=== === === >> +BitsBinary valueDescription >> +=== === === >> +5-4 00 *UseStream0* >> +.. 01 *UseStream1* >> +.. 10 *UseStream2* >> +.. 11 *UseStream3* >> +6 0 --- >> +.. 1 *ReadFilterId* >> +7 0 **BasicCompression** >> +=== === === >> + > > ReadFilterId is never explained. It is explaned how it works though, first parapraph below **BasicCompression**. But I agree that this is not enough. > And the rest of the document uses lower case and dashes for keywords. Not consistently, but I agree. >> +Otherwise, if the bit 7 of *compression-control* is set to 1, then the >> +compression method is either **FillCompression** or >> +**JpegCompression**, depending on other bits of the same byte: >> + >> +=== === === >> +BitsBinary valueDescription >> +=== === === >> +7-4 1000**FillCompression** >> +.. 1001**JpegCompression** >> +.. any other invalid >> +=== === === >> + >> +Note: **JpegCompression** may only be used when *bits-per-pixel* is >> +either 16 or 32. > > Is this really a requirement, or just how the servers are implemented? > I.e. will the clients cope with that method when bpp is 8? Don't think so. My implementation will not. > We should also mention that the server must not use JPEG when no > quality level has been selected. > > (I know this is mentioned in your next patch, but it should be pointed > out here as well for clarity) Right. I agree. >> +**FillCompression** >> + >> +If the compression type is "fill", then the only pixel value >> +follows, in client pixel format (see [NOTE1]_). This value applies >> +to all pixels of the rectangle. > > These tight specific pixels are used everywhere. Perhaps they should be > mentioned early, like CPIXEL for ZRLE? > > And when you mention "fill" like that, it seems like you're referring > to some canonical name. I suggest to just leave those kinds of short > names out and just the **FillCompression** type of names. > >> +**JpegCompression** >> + >> +If the compression type is "jpeg", the following data stream looks >> +like this: >> + >> +=== === === >> +No. of bytesTypeDescription >> +=== === === >> +1-3 *length* in compact >> +representation >> +*length*``U8`` array*jpegData* >> +=== === === >> + >> +*length* is compactly represented in one, two or three bytes, >> +according to the following scheme: >> + >> +=== === >> +Value Description >> +
Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.
On Thu, 11 Jun 2009 13:30:41 +0200 Peter Rosin wrote: > +The least significant four bits of *compression-control* byte inform > +the client which zlib compression streams should be reset before > +decoding the rectangle. Each bit is independent and corresponds to a > +separate zlib stream that should be reset: > + > +== > +BitDescription > +== > +0 if 1: reset stream 0 > +1 if 1: reset stream 1 > +2 if 1: reset stream 2 > +3 if 1: reset stream 3 > +== I think the "if 1:" part is implied. :) > +One of three possible compression methods are supported in the Tight > +encoding. These are **BasicCompression**, **FillCompression** and > +**JpegCompression**. If the bit 7 (the most significant bit) of > +*compression-control* byte is 0, then the compression type is > +**BasicCompression**. In that case, bits 7-4 (the most significant four > +bits) of *compression-control* should be interpreted as follows: > + > +=== === === > +BitsBinary valueDescription > +=== === === > +5-4 00 *UseStream0* > +.. 01 *UseStream1* > +.. 10 *UseStream2* > +.. 11 *UseStream3* > +6 0 --- > +.. 1 *ReadFilterId* > +7 0 **BasicCompression** > +=== === === > + ReadFilterId is never explained. And the rest of the document uses lower case and dashes for keywords. > +Otherwise, if the bit 7 of *compression-control* is set to 1, then the > +compression method is either **FillCompression** or > +**JpegCompression**, depending on other bits of the same byte: > + > +=== === === > +BitsBinary valueDescription > +=== === === > +7-4 1000**FillCompression** > +.. 1001**JpegCompression** > +.. any other invalid > +=== === === > + > +Note: **JpegCompression** may only be used when *bits-per-pixel* is > +either 16 or 32. Is this really a requirement, or just how the servers are implemented? I.e. will the clients cope with that method when bpp is 8? We should also mention that the server must not use JPEG when no quality level has been selected. (I know this is mentioned in your next patch, but it should be pointed out here as well for clarity) > +**FillCompression** > + > +If the compression type is "fill", then the only pixel value > +follows, in client pixel format (see [NOTE1]_). This value applies > +to all pixels of the rectangle. These tight specific pixels are used everywhere. Perhaps they should be mentioned early, like CPIXEL for ZRLE? And when you mention "fill" like that, it seems like you're referring to some canonical name. I suggest to just leave those kinds of short names out and just the **FillCompression** type of names. > +**JpegCompression** > + > +If the compression type is "jpeg", the following data stream looks > +like this: > + > +=== === === > +No. of bytesTypeDescription > +=== === === > +1-3 *length* in compact > +representation > +*length*``U8`` array*jpegData* > +=== === === > + > +*length* is compactly represented in one, two or three bytes, > +according to the following scheme: > + > +=== === > +Value Description > +=== === > +0xxxfor values 0..127 > +1xxx 0yyy for values 128..16383 > +1xxx 1yyy for values 16384..4194303 > +=== === > + > +Here each character denotes one bit, xxx are the least > +significant 7 bits of the value (bits 0-6), yyy are bits 7-13, > +and are the most significant 8 bits (bits 14-21). For > +example, decimal value 1 should be represented as two bytes: > +binary 1001 0
