Adam Tkac wrote: > If I understand correctly you are proposing separate messages (with > "messages" I mean multiple rectangles with different encodings) for > JPEG and quality levels. Communication client<->server will look like: > > client->server JPEG encoding is supported > server->client Framebuffer update encoded in JPEG > client->server Change quality to level X > > With this approach you pollute "encodings namespace" with 100 new > encodings which should be bound to the JPEG encoding. > I propose different approach. JPEG client->server message will include > information about quality level. Main difference with my and your > proposals is that you've added 100 new encodings but I've added only > one JPEG encoding. > Won't that break compatibility with TurboVNC and TightVNC? Or was the intent to keep the existing Tight JPEG mechanism as well and just use the new JPEG encoding only if both client and server support it? There are very real and provable advantages to the Tight scheme of using JPEG for high-color-depth tiles and paletted encoding for low-color-depth tiles. We don't ever want to use just pure JPEG encoding for the whole framebuffer. However, my understanding of what is being proposed by you and Pierre and others is that we want to eventually be able to compress individual tiles using different encodings and deprecate the Tight mechanism of using subencodings.
I'm less concerned with being able to use, for instance, a TigerVNC viewer to send fine-grained quality updates to a TurboVNC server, because we aren't planning to expose the fine-grained quality controls anyhow. Their main purpose is so that the automatic quality adjustment code can "zero in" on an appropriate quality that meets the desired bandwidth/performance constraints, so this stuff will all be taking place behind the scenes. However, the counter arguments I would make are: (1) It's not like we're running out of encoding numbers or anything. We have billions of them available, so "encodings namespace pollution" is perhaps overstating the issue a bit. (2) Tight quality and compress level are already set using the above mechanism. (3) TurboVNC has been using these encodings unofficially for five years. It would be nice to make them official, irrespective of whether or not we replace them with a new mechanism, because it would prevent anyone else from trying to use them and provide a bridge for us until we can implement our long-term scheme. >> If we can't extend Tight encoding, then my counter-proposal would be to >> create a new rfbEncodingTightNoZlib method. >> > > The Tight encoding is tricky. It is `owned` by Constantin Kaplinsky > and the TightVNC project. I think we should not touch it unless > Constantin approves the change. Btw could I ask you why would you like > to create such encoding? > It enables a particular lossless mode whereby paletted encoding is used for low-color-depth tiles and uncompressed raw pixels are sent for high-color-depth tiles. This is used in TurboVNC 0.5 as a much faster (and generally lower bandwidth) alternative to Raw and Hextile encoding and is useful in several scenarios, including connecting to a local VNC server, re-compressing and redisplaying the output of vncviewer, or in situations in which you simply have a lot of network bandwidth and want to conserve server CPU time as much as possible. In order to reduce CPU time, it is necessary to bypass Zlib encoding, because Zlib with compress level 0 still has a lot of CPU overhead, even though it isn't actually compressing. An alternative proposal was to modify Zlib to fix this issue, but it's a very old code, and I'm dubious as to our ability to get changes to it put back into the master code base. However, if we ultimately implemented a higher level sort of scheme whereby individual tiles could use different encodings, then implementing the above would be a simple matter of assigning Raw encoding to some tiles and Tight encoding (or a new, separate paletted encoding scheme) to others, based on their color counts. rfbEncodingTightNoZlib was an admitted hack, and since it wasn't introduced until TurboVNC 0.5, there is much less of a legacy concern here. _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
