Re: [VirtualGL-Devel] Some questions on TurboVNC vs Libvncclient

[DRC <dco...@us...>]

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.