On Thu, Sep 03, 2009 at 06:04:59AM -0500, DRC wrote: > 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.
AFAIK the Tight encoding is a mechanism to encapsulate other encodings thus you end with something like a "protocol inside protocol" (The Tight encoding already has many sub-encodings like FTP-like transfer related encodings and the JPEG encoding as you wrote above). I really don't like such approach because it might end with crippled and badly designed protocol. I would really like to see the Tight encoding and sub-encodings mechanism deprecated. But it won't happen soon. > 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. The number of possible encodings is not a limitation. I would like to point that adding stuff, which is _very_ closely bounded to the existing encoding (Tight encoding with JPEG subencoding in this case), as a separate encodings is not a good idea. In my opinion the image quality related extensions should be delayed till new JPEG encoding (not the Tight->JPEG encoding) gets created or add image quality related stuff as Tight subencoding. > (2) Tight quality and compress level are already set using the above > mechanism. Yes, of course, because the Tight encoding is the protocol inside RFB protocol. > (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 TurboVNC uses this mechanism long time then it's a good idea to prevent someone from using them. But I would like to see a comment that those encodings should not be used in new implementations. Is it acceptable for you? > >> 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. AFAIK individual tiles could already use different encodings and I think this approach should be preferred. > rfbEncodingTightNoZlib was an admitted hack, and since it wasn't > introduced until TurboVNC 0.5, there is much less of a legacy concern here. Then you can probably mail to Constantin and tell him you've extended the Tight extension. Regards, Adam -- Adam Tkac, Red Hat, Inc. _______________________________________________ VNC-List mailing list VNC-List@realvnc.com To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
