Only libvncserver has been optimized thus far. It would be very straightforward to optimize libvncclient as well, and a lot more expedient. Most of the time spent optimizing libvncserver involved back & forth with the developers, who were concerned about the use of the TurboJPEG wrapper as well as changing the behavior of the Tight encoder. I ultimately had to do a lot of pro bono research to prove that it was possible to make the TurboVNC encoder encode as "tightly" as the TightVNC encoder, and a new compression level (CL 9) had to be added to provide backward compatibility with the "tightest" modes of compression in TightVNC. CL 9 only compresses something like 10-20% better than CL 2 on 2D workloads (and makes no difference on 3D/video workloads), and it uses twice the CPU time of CL 2, so it is not recommended for general use. However, this was ultimately what assured the developers that users would not be losing any functionality by moving to the TurboVNC encoder.
The modifications to libvncclient would simply be optimizations, most of them directly ported from the Unix TurboVNC Viewer code base. libvncclient is already able to use libjpeg-turbo, but the further optimizations would allow it to decode directly to the framebuffer (using the libjpeg-turbo colorspace extensions) and to increase the performance of the indexed color lookup algorithms, etc. I am interested in doing that work, but since it's not something that I could generate revenue from in the near term (i.e. not something that would benefit VirtualGL and TurboVNC), it's hard to justify doing it unless someone stepped forward to sponsor the effort. On 8/22/13 4:34 PM, Göran Krampe wrote: > Hi! > > I am looking at integrating applications into a "virtual reality" world > (we have already done this but using our own VNC and RDP code) and I am > getting intrigued by a solution that would look something like this: > > For VNC apps (Linux desktop apps), run them on the Linux server using > TurboVNC and VirtualGL and then take the Remmina codebase and turn it > into a library that we then can call from our system (that is not > written in C). So the VNC plugin (uses Libvncclient) in Remmina would be > our "client" side. > > Question: Is the latest Libvncclient codebase "as good" as the TurboVNC > viewer when using TurboVNC/VirtualGL on the server side? The 0.9.9 > release says "the new TurboVNC encoder", and I did skim through the > conversation on that stuff - but did all the "improvements" in the > TurboVNC client get into Libvncclient 0.9.9? > > My non scientific testing so far seems to indicate very good performance > of this setup. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
