Use Arithmetic or Progressive Huffman Encoding to Improve JPEG Compression on Low-Bandwidth Networks about turbovnc HOT 5 CLOSED

I don't care for option three (jpeg is jpeg), and I disagree about it being more flexible (options are options and can be added as needed or useful). As to which compression level we use, the presented interface is that the larger the number the more processor is traded for bandwidth efficiency, I believe the best policy is to allow shuffling compression levels as needed to best fit that assumption, and that no guarantee of any specific meaning be assigned to any given value.

from turbovnc.

That makes sense. The only reason why I suggested possibly using a separate RFB pseudo-encoding is that, traditionally, the compression level in TightVNC-compatible solutions is independent of the JPEG encoding settings. That's because you can specify different compression levels even if JPEG isn't enabled. However, there is no reason why TurboVNC has to adhere to that standard. Our approach has traditionally been to expose only the encoding combinations that have been proven to provide useful trade-offs. For instance, in TigerVNC and TightVNC, any compression levels above 5 are essentially useless. They don't increase the compression ratio by more than a couple of percent on average relative to CL 5, and they increase CPU usage by as much as 4-5x. So TurboVNC's "extreme" compression mode (CL 9) is currently calibrated to emulate the compression ratio of TightVNC's CL 5. We added that mode at the behest of the libvncserver developers, who were concerned that replacing the TightVNC encoder with the TurboVNC encoder would reduce the overall "tightness" of the solution. They wanted a mode that would provide equivalent compression for 2D applications without using any more CPU time, regardless of whether the library was compiled with libjpeg or libjpeg-turbo. CL 9 in TurboVNC actually comes within 1% on average of the compression ratio of TightVNC CL 5 for 2D applications, while providing 10% better performance. For 3D applications, it is about 60% tighter and 2x as fast as TightVNC CL 5. However, when you look at it in terms of incremental improvements, it works like this:

TurboVNC CL 1 to TurboVNC CL 2: ~19% better compression and ~13% more CPU usage for 2D app workloads, ~13% better compression and ~20% more CPU usage for 3D app workloads (good trade-off)

TurboVNC CL 2 to TurboVNC CL 9: ~18% better compression and ~2x the CPU usage for 2D app workloads, ~7% better compression and ~2.25x the CPU usage for 3D app workloads (not such a good trade-off)

That's what I mean when I say that CL 9 currently has little or no usefulness for 3D applications, and the trade-off for 2D applications is less than favorable as well. However, if we can compress JPEGs 20% more, that will change the fundamental assumptions about CL 9, and it may be possible to re-design it such that it has a better trade-off. Or we can simply move the existing CL 9 to CL 8 and make arithmetic coding the new CL 9. I would need to do some low-level experiments with the TurboVNC Benchmark Tools to determine the best approach.

from turbovnc.

Agreed.

from turbovnc.

Another possibility here would be to integrate a set of SSE2 SIMD extensions for progressive Huffman encoding. Those extensions have been submitted to libjpeg-turbo, but they are in need of funding for integration and testing labor:
libjpeg-turbo/libjpeg-turbo#46

The amount of compression from prog. Huffman wouldn't be as high as arithmetic coding, but the performance would be much better. Accelerating the arithmetic codec in libjpeg-turbo would be a relatively large undertaking, and it would have to be accelerated on both the client and server side in order to achieve sufficient performance. To put some numbers on this:

Across the set of test images I typically use for libjpeg-turbo testing, which includes three 3D application screen captures (http://www.libjpeg-turbo.org/About/Performance), arithmetic coding compresses about 15% better than baseline on average, with an 5x drop in compression performance and a 6x drop in decompression performance (also on average.) With the SIMD-accelerated progressive Huffman codec, we'd be looking at about a 10% improvement in compression (on average) with a 4x drop in compression performance and a 3x drop in decompression performance. That would still put the compressor in the range of about 15-30 Megapixels/sec and the decompressor in the range of 30-40 Mpixels/sec, which is enough to achieve at least usable frame rates on a 2-megapixel screen.

from turbovnc.

Unfortunately, this just didn't bear out the way I had hoped. Even with the 2X improvement in progressive JPEG encoding performance in libjpeg-turbo 2.0, adding progressive Huffman encoding to the existing Compression Level 9 (tested with both Medium-Quality and Low-Quality JPEG) reduced the Tight encoding performance by about 25% for only a 4-5% overall gain in compression ratio for 3D applications. Not worth it.

from turbovnc.