Hi! On 08/22/2013 11:56 PM, DRC wrote: > 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.
Ok! Good. > 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 Yeah, that must be why it seems to do "youtube" more or less as good as the turbo client does (my eyes can't see much difference, but I am running all locally). > 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. I will keep it in mind, later it might very well turn out to be something we would want - if we take this route we probably want to squeeze out all we can. The reason I am looking at taking the Remmina codebase (and not the TurboVNC client directly or Libvnclient directly) is because Remmina also has FreeRDP (and NX) and the FreeRDP project is doing very well these days. And oh, I did actually try running the FreeRDP client from inside the TurboVNC client and it worked quite well! But insane. ;) Did you see that they implemented the RemoteFX codec (libfreerdp-rfx) - both encode/decode with SSE2 acceleration? That must be something worth testing as another option in TurboVNC? I don't know how it would compare to libjpeg-turbo (it is some wavelet algorithm) but I think its good stuff. It is available on github in their repo: https://github.com/FreeRDP/FreeRDP/tree/master/libfreerdp/codec I also note they are experimenting with both an x11 RDP server and a server for Windows. The Windows server (how to capture on Windows has been discussed here in other threads) is using the new "Desktop Duplication API" that was introduced in Windows 8 that also TightVNC is using in their latest release: http://www.tightvnc.com/release-2.7.php Btw, I looked at the vglrun shell script and AFAICT it simply uses the LD_PRELOAD trick. If I turn Remmina into a dynamic library and compile it myself, I presume it is easy to make sure I get the faker lib and not having to use vglrun? I am not a hardcore C/C++ guy, but I can push myself through things ;) Ah, another silly question - the IPP version of libjpeg-turbo, how do I use that? 3-4x faster sounds interesting. regards, Göran ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
