Under sponsorship by Cendio, I have completed an extensive (as in 100+
hours) set of performance optimizations to the TigerVNC Server in trunk,
which should bring its performance completely in line with TurboVNC,
provided that the ComparingUpdateTracker is disabled. I am
investigating the afore-mentioned issue with that whereby it is sending
twice as much data as it should when legacy clients are connected, and
pending a fix for that, I will likely recommend disabling the tracker as
the default.
The process of optimizing the server involved the following steps:
(1) High-level benchmarking and differential performance analysis to
determine the baseline relative to TurboVNC. TigerVNC trunk was
determined to be about 30-40% slower at the high level, and at the low
level, the server was using about 65% more CPU time to encode the same
data as TurboVNC.
(2) Low-level analysis of the encoder using the processes described in
the following reports:
http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf
http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf
In a nutshell, the encoder was studied in isolation using a set of
low-level RFB performance tools and protocol captures. The link to the
code for these tools, including the isolated TigerVNC 1.1 and 1.2
encoders, is provided in the reports. The isolated encoder has already
proven its usefulness in other areas (I used it to isolate the Zlib bug
and verify the low-level stability of the fix.)
(3) After the low-level analysis was complete, I started integrating the
modified encoder back into TigerVNC, only to discover that one of the
main performance features that was added to it-- the pre-computation of
solid rectangles-- required another feature: last rectangle encoding.
Thus, I had to implement last rectangle encoding in the TigerVNC
transport layers.
(4) At this point, we had an encoder that produced the same output as
TurboVNC and performed similarly to TurboVNC at the low levels, but the
high-level performance was still lacking. This was due to two factors:
(a) the afore-mentioned ComparingUpdateTracker, and (b) the image
getter. The process of getting the images from the framebuffer to the
encoder was very inefficient. Thus, I went back and overhauled the
encoder again, this time porting in the code from TurboVNC that allows
the encoder to compute solid rectangles, count colors, and compress JPEG
directly from the framebuffer without transforming the pixels first.
This involved some re-architecture to several of the classes in librfb
to allow access to the virtual FB from within the encoders. There is
probably a cleaner way to do what I did, but IMHO, it's at least cleaner
now than it was.
As of now, with the ComparingUpdateTracker disabled and using our FLTK
viewer, the performance is at about 85-90% of TurboVNC at the high
levels, and the remaining gap is entirely due to the viewer. The server
CPU usage is now almost exactly the same as TurboVNC. Whereas the FLTK
viewer is a bit more efficient than the old X viewer, it still needs
some optimization work, which I'll begin looking at next month.
In the meantime, please be on the lookout for potential performance
pitfalls in the new encoder, particularly on low-bandwidth networks. If
you discover situations in which the new Xvnc appears to produce worse
performance than the old Xvnc, please try your best to quantify the
difference and verify whether jacking up the compression level a notch
or two restores the performance you expect (it should, unless I miss my
guess.)
The viewer GUI has also been modified to reflect the findings from the
low-level performance study (specifically, that compression levels
higher than 3 rarely have any benefit and compression levels higher than
6 never do. Also, compression level 1 is now the default, since it
offers the best "bang for the buck.") It is still possible to enter
level 7-9 in the GUI or specify it from the command line, but IMHO, we
should pretend as if those levels don't officially exist anymore. If
someone can show a case in which levels 7-9 produce a demonstrably
better result than 6, I am eager to examine it.
DRC
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
