The attached spreadsheet tracks the overall performance of JPEG image delivery in TigerVNC since I started working on the project. This E-Mail will walk you through the analysis.
I first ran revision 3757 against 3759 to measure the effect of the colorspace enhancements. I found the effect to be negligible (< 5%), so I would recommend backing off to 3757 for this release, and I can re-investigate those enhancements post 1.0.0. I think part of the problem is that there is still a buffer copy happening in TransImageGetter, so this probably hides the boost due to the enhanced colorspaces. After 1.0.0, one of the first mods I'll try to make is to compress JPEG directly out of the PixelBuffer whenever no pixel translation is required. After measuring the effect of the colorspace enhancements, I then ran 3757/3759 with '-deferUpdate 1' on the server, which improved overall performance by approximately 40%. I strongly recommend that we add '-deferUpdate 1' to the vncserver script for this release so that this performance boost becomes the default. The performance boost due to '-deferUpdate 1' is not surprising at all. Whenever Pierre enabled pipelining of the framebuffer update requests in the client, this created a situation identical to that of TurboVNC 0.3.2. Effectively, all of the frames on the server were being deferred, so the performance enhancements due to the improved libjpeg were at least partially hidden. Enabling '-deferUpdate 1' creates a situation similar to that of TurboVNC 0.4, which should be optimal on both high-latency and low-latency networks. I then generated a hybrid build of TigerVNC with revision 3663 of libjpeg (a revision from right before I committed my first enhancements) but with latest & greatest of everything else. This was to show the effect solely of the libjpeg enhancements (mainly the Huffman codec) on the overall performance of the code, which amounted to: 37% improvement in the client and 26% improvement in the server, when the deferred update timer was set to the default value (40 ms) 53% improvement in the client and 42% improvement in the server, when the deferred update timer was set to 1 ms (this is what I mean by the deferred update mechanism "hiding" some of the libjpeg performance boost.) With '-deferUpdate 1', then the overall performance improvement since 3732, which includes all of Pierre's color conversion optimizations, my libjpeg optimizations, the parallel FUR, etc., will be approximately 66%. We would still be about 40% slower than what I think is achievable in the long term (based on the TurboVNC numbers), and obviously this just addresses JPEG. The indexed encoding routines also need optimizing, as well as the interplay between the two (the latter would bring us more in line with TurboVNC 0.5.) In short, apart from adding 'deferUpdate 1' to vncserver, I think 3757 is ready. Pending everyone's approval, can someone make that vncserver change and also back out 3758 and 3759? DRC
tigervncvsturbovnc.ods
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
