On 10/2/12 5:21 AM, Pierre Ossman wrote: >> The attached adds support for the unofficial rfbTightNoZlib extension >> used by the TurboVNC Server to transmit Raw, indexed color, and mono >> subrectangles without Zlib compression. This prevents the TigerVNC >> Viewer from crashing if the user attempts to select Compress level 0 >> while connected to a TurboVNC server. >> > > The principle is reasonable, but is this an officially allocated > number? > > You seem to be using it as a bit, even though it isn't a single bit. I > don't see how that can work. "fill" | "nozlib" == 0x08 | 0x0A = 0x0A. So > masking off "nozlib" does not give you back "fill", but 0x00. > > And I see no code for telling the server that the client supports the > extension.
Well, bear in mind that this extension has been in use for 5 years quite successfully in TurboVNC, so it definitely works correctly. It is also now in libvncserver, so there is at least de facto adoption of it. No, it isn't officially allocated, but there are no conflicts of which I'm aware (see below regarding rfbTightPNG.) From rfbproto.h: /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * Tight Encoding. * *-- The first byte of each Tight-encoded rectangle is a "compression control * byte". Its format is as follows (bit 0 is the least significant one): * * bit 0: if 1, then compression stream 0 should be reset; * bit 1: if 1, then compression stream 1 should be reset; * bit 2: if 1, then compression stream 2 should be reset; * 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 "basic" and no * Zlib compression was used, * if 1110 (0x0E), then the compression type is "basic", no Zlib * compression was used, and a "filter id" byte follows this * byte, * if 0xxx, then the compression type is "basic" and Zlib * compression was used, * values greater than 1010 are not valid. * * If the compression type is "basic" and Zlib compression was used, then bits * 6..4 of the compression control byte (those xxx in 0xxx) specify the * following: * * bits 5-4: decimal representation is the index of a particular zlib * stream which should be used for decompressing the data; * bit 6: if 1, then a "filter id" byte is following this byte. As you can see, the protocol is designed such that some constants act as bit masks and some constants act as enumerators (that wasn't my design-- it was Constantin's.) Since we've already right-shifted comp_ctl by 4, bits 7-4 are now in bits 3-0, but I'll still refer to them as bits 7-4 to be consistent with the above. The decoder checks whether comp_ctl & 0x0A == 0x0A, which it only will be if comp_ctl is 0x0A or 0x0E. If it's equal to rfbTightFill or rfbTightJpeg, then the test is false, but no worries, because Zlib is irrelevant for those two subencoding types. If comp_ctl is 0x0A or 0x0E, we mask off bits 5 and 7, so we're left with bit 6 to indicate whether a "filter ID" byte follows (filter ID's are used with indexed color or with the obsolete gradient encoding. If a filter ID is not present, then that means the subrectangle uses raw subencoding.) There is no code to tell the server that the client supports the extension. The TurboVNC Server will always use rfbTightNoZlib when it receives a request for compression level 0 without JPEG. Other servers, such as the TigerVNC Server, don't support the extension, but with this patch, the viewer can now decode streams from both. Given that compression level 0 is not even documented with most VNC viewers (including TigerVNC), this is almost a "hidden" mode with anything but the TurboVNC Viewer. There are a significant number of users in the TurboVNC community, however, who take advantage of TurboVNC's Lossless Tight mode (and yes, I know that's an oxymoron) on fast networks, particularly if they are using it to transmit pixels internally from a Linux server to a Citrix server that does the final image compression. In those cases, JPEG can fool Citrix's interframe differencing engine, and it also adds unnecessary CPU overhead. TigerVNC has never used the TightVNC capabilities registry, which would be a great way to inform the client and server of their support of this extension (not to mention others.) When integrating the TurboVNC encoder with libvncserver, we discovered that rfbTightPNG (the enumerator for the experimental PNG subencoding type) is also 0x0A. It acts very much like rfbTightJpeg and rfbTightFill. However, TightPNG is a different encoding type from Tight, so there is no conflict, since rfbTightNoZlib is used only with rfbEncodingTight and rfbTightPNG is used only with rfbEncodingTightPNG. ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
