The best-performing client to use with TigerVNC is either TigerVNC or TurboVNC, because both have accelerated Tight decoding (the code for which I personally wrote for both projects.) Using the TigerVNC server also offers tremendous performance benefits with Tight encoding, relative to the TightVNC server.
However, since the client in question only supports RFB 3.3, that means it can only potentially decode Raw, RRE, CoRRE, and Hextile (and possibly only a subset of those.) None of those encodings are accelerated in TigerVNC, but I can't imagine that TigerVNC's implementation of them is any slower than TightVNC's. That being said, it may be that the client is trying to use CoRRE (which is the only one of those four encodings not supported by the TigerVNC server) and is falling back to Raw. I am not trying to hijack this list to promote my own VNC project, but since TurboVNC was based on TightVNC 1.3.x originally, our server still has legacy support for CoRRE, so it would be worthwhile to test it and see if it magically fixes the issue. If so, then that would validate the hypothesis that your client requires CoRRE to achieve decent performance, and it would be straightforward enough to add that functionality to the TigerVNC server (not that I'm volunteering.) Otherwise, I'm clueless. On 5/9/13 2:17 PM, Jay Ashworth wrote: > I've just upgraded a client from TightVNC 1.3.10, supplied as RPM with > an ancient version of SuSE, to Tiger 1.2.0 from binary tarball. > > The relevant clients are TightVNC/win (RFB 3.8), and Axel 75 terminals, > with an embedded client using RFB 3.3. > > The OS is OpenSUSE 12.1, with a 3.0 kernel. > > We were using the ancient Xvnc because the one supplied with OpenSUSE 12.1 > ignored mouseclicks completely from all client versions (including the > TightVNC/Linux 1.3.10 client I test with on my laptop). The ancient one > was working fine until I upgraded them to SuSE 12.1, and the KDE3 which > comes with that; that setup wouldn't support drag and drop. > > Upgrading to Tiger 1.2 got me back DnD, but now the old Axel terminals appear > to have noticeably slow repaint -- the user can *see* the square tiles paint > from left to right, top to bottom. > > He says the session paints fine from his Windows VNC client at home, and > I didn't see any slow paint in my Linux Tight client either, so this > seems to be something related to the ancient VNC client implementation > on the Axel terminals, which as I note above, identify themselves as > RFB 3.3. > > Anyone sufficiently familiar with the Tiger internals to point me towards > something to look at? > > The command line is: > > Xvnc.tiger :11 -desktop 'X' -auth /appl/home/scobey/.Xauthority -geometry > 1280x1024 -depth 16 -rfbwait 120000 -rfbauth /appl/home/scobey/.vnc/passwd > -rfbport 5900 -interface 192.168.112.17 -alwaysshared -fp > /usr/share/fonts/misc/,/usr/share/fonts/75dpi/ >> > '/var/log/vnc/patriot:11.log' 2>&1 > > and everything else seems to be working ok, except the paint speed. > > I can produce X.log contents if necessary, but there seems not much > in there that is relevant (note: a *lot* more logging on start up > and connection would be really handy, devs :-) > > Cheers, > -- jra > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
