Attached is a spreadsheet comparing TurboVNC 0.5.1 and the current SVN snapshot of TigerVNC at the high level (the snapshot of TigerVNC I used includes Pierre's double buffering enhancements.) The methodology used to compare the two was the same methodology as used in the VirtualGL 2.1 Performance Study: http://www.virtualgl.org/pmwiki/uploads/About/vglperf21.pdf, using the benchmarking tools provided by the VirtualGL package.
Both VNC servers were run in 24-bit mode with a resolution of 1240x900, and the JPEG quality was set to equivalent levels (8 in TigerVNC, 4:4:4 Q92 in TurboVNC.) GLXspheres and VirtualGL were run in full-screen mode inside the VNC sessions, and TCBench was used to measure the frame rate on the client end (average of two runs of TCBench.) CPUstat was then used on the server to compute the average CPU usage, then NetTest was used to measure the average network usage over a period of 50 seconds. These figures were then used to compute the following metrics: Encoding time: the number of milliseconds, on average, that it took to encode a single frame on the server Frame size: the average number of bits that it took to represent a frame on the network When run normally, GLXspheres outputs a series of 3D images with about 60-70% screen coverage. These images contain a lot of differently-colored smooth-shaded spheres and thus are good tests of the full-color encoding paths in TigerVNC/TurboVNC. Generally, these images cause TigerVNC/TurboVNC to use almost all JPEG or almost all Raw tiles. GLXspheres was additionally run in "low color mode", which causes each sphere to be rendered with no lighting or shading. This produces a very flat image with less than 25 colors, and this causes TurboVNC/TigerVNC to use almost all paletted encoding to transmit the image tiles. To provide a fair comparison, I ran the TurboVNC server and client with the Open mediaLib codec in addition to the IPP codec. We've established that the OML codec performs approximately the same as libjpeg/SIMD at the low level. Also, both servers and clients were compiled as 32-bit, which allowed TigerVNC to use its optimized JPEG codec. In general, the JPEG encoding is still significantly slower in TigerVNC than in TurboVNC (by more than a factor of 2.) As you can see, this is almost entirely attributable to an increased encoding time on the server (about 80 ms per frame instead of 40.) I will work on improving this over the next few days.
tigervncvsturbovnc.ods
Description: Binary data
------------------------------------------------------------------------------
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
