Last year, I got involved in a project to port the TurboVNC encoder into libvncserver, and in the process of doing this, I had to prove that the Turbo encoder was capable of producing at least roughly equivalent compression to the "tightest" modes in the TightVNC encoder. There are lengthy threads on the libvncserver mailing list that I am happy to provide links to for the morbidly curious, but I'll summarize the findings here. The research revealed that, for starters, any compression level greater than 5 in TightVNC was wholly useless. It increased CPU time by as much as an order of magnitude without any significant compression ratio increase for the test datasets (which include Constantin's original 2D datasets that were used in the design of the Tight encoder, as well as 3D datasets I provided.) In some cases, going from CL 5 to CL 9 actually decreased the compression ratio. This is known to be true of TigerVNC as well (referring to http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf).
It was also discovered that CL 2 in TurboVNC (or TigerVNC) could not quite achieve the same compression as TightVNC in all cases, so I developed a "TightVNC replacement" mode in TurboVNC, a mode that strongly favors the use of Zlib-encoded subrectangles instead of JPEG-encoded subrectangles. Basically, it sets the "palette threshold" to 256, so all subrectangles that have 256 or fewer colors are encoded using indexed color (normally, the palette threshold is set to 24 or 96, so any subrectangles with more than that number of colors will be encoded using JPEG.) The "TightVNC replacement mode" provides equivalent or better compression to the "tightest" mode (CL 5) in TightVNC across all of the datasets, while using much less CPU time in general. The other thing about these compression levels is: once you get past CL 2, the incremental difference in each level starts becoming less and less. What I observe in TurboVNC is that: moving from CL 1 to CL 2: -- results in about a 15-20% aggregate bandwidth savings for 2D apps, while using on average about 20% more CPU time -- results in about a 10-15% aggregate bandwidth savings for 3D apps, while using on average about 15-20% more CPU time (there are a couple of outlying app workloads that see a 30-40% bandwidth savings, but these are not the common case.) moving from CL 2 to the "TightVNC replacement mode": -- results in about a 15-30% aggregate bandwidth savings for 2D apps, while using on average about 20-40% more CPU time -- results in about a 7% aggregate bandwidth savings for 3D apps, while doubling the CPU time So, as you can see, anything more than CL 2 is not useful for 3D apps, and for 2D apps, pretty extreme measures are required in order to achieve the same incremental compression increase as that which is achieved by going from CL 1 to CL 2. My proposal is for TigerVNC to adopt four compression modes: CL 0, CL 1, CL 2, and CL 5. CL 3 and 4 would map to 2, and CL 6-9 would map to 5, and the GUI could be restructured so that it sets the compression level to "low, high, and very high", with a warning that "very high" is only better than "high" in some rare cases. Just a suggestion. I can provide a server-side patch for this if requested. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
