On 5/30/13 2:49 PM, Jay Ashworth wrote: > When I upgraded them to SuSE 12.1, the replacement Xvnc from the new Tight > package wouldn't accept mouseclicks, so I again copied in the older one, > and *it*, in its turn, wouldn't allow drag and drop, though everything > else seemed to work ok. They lived with that for a while, and it's gone > critical on me again, so I dug back into the problem, and tried out TigerVNC, > since the Tight people tell me they aren't building for X/Linux anymore > (which seems to me to be a pretty fine how d'you do...)
TurboVNC is basically the continuation of that code base. We were initially just a more optimized version of TightVNC 1.3.x, but that was nearly 9 years ago. Since then, we have pulled in code from X.org and xf4vnc (to add additional X extensions, such as RENDER, that weren't present in TightVNC), made numerous functional, performance, and stability enhancements, added 3D-specific features such as automatic lossless refresh, and borrowed some of the technology from TigerVNC as well (most notably a lot of the Java viewer code, as well as the RFB flow control extensions.) In exchange, TigerVNC got many (but not all) of our Tight codec performance enhancements. In the process of integrating the TurboVNC encoder into libvncserver, I did a lot of research to find a set of 3 compression modes (see http://virtualgl.svn.sourceforge.net/viewvc/virtualgl/vnc/tags/1.2/doc/index.html#hd007002) that will basically cover all of the bases that TightVNC once covered, and generally with a great deal more performance. With the soon-to-be-implemented client-side multi-threading, I anticipate that we'll leap ahead yet again in the performance department. I am confident that TurboVNC covers all of the bases that TightVNC 1.3.x once covered. > A birdie whispered in my ear that TurboVNC was being developed a little > more actively than Tiger, so I went and grabbed that. I would say that the fundamental difference between that project and ours is one of philosophy. TigerVNC relies upon a vendor (such as Red Hat, for instance) to stabilize and produce an enterprise-quality product from the source code. The principal developers are getting better at feeding back this stabilization process into the open source project, so 1.3 beta actually means something now, whereas 1.2 beta largely didn't, and 1.1 was entirely for my benefit (the principal developers had already abandoned that branch by the time it was ready to stabilize.) It is still the case, however, that pretty much everyone builds and deploys TigerVNC differently, and most don't use the process described in BUILDING.txt, so bugs that one person experiences are sometimes impossible for other developers to reproduce (I speak from first-hand experience there.) TurboVNC, on the other hand, is designed such that all of the processes used to generate our enterprise-quality binaries (even down to the exact build scripts we use) are fully open and transparent and cross-compatible. Thus, our X server is self-contained, so we don't have to deal with multiple X server code bases and multiple incompatible dependencies and multiple build processes. This gives us full control over the quality of the solution. There are trade-offs to that approach, which are spelled out here: http://www.virtualgl.org/About/TigerVNC. However, definitely those who were familiar with TightVNC 1.3.x will find TurboVNC to be more similar in concept. > It seems to work about as well, or a little faster, than Tiger, *with the > PC/Linux/Mac based clients... but now the Axel terminals (with RFB3.3 > capable VNC firmware in their ROMs) *say they have connected*, but never > paint a screen at all. > > A server X.log from the server for my "testuser", with connections from > the LAN and from outside, is posted here, with a 1 month expiration: > > http://pastebin.com/0Pe9CVpp This appears to be a legit bug, and I can easily reproduce it using the RealVNC 3.3.7 Windows client. Will investigate. > You'll note a bunch of extension missing messages; I had to trim out > almost 25MB of those to make the paste; they're being generated > constantly, and only by Turbo. Tiger and Tight don't seem to drop those. Not sure why TightVNC wouldn't be throwing the same errors, since it has about the same set of X extensions. Two things to try: (1) It might be that our startup script (~/.vnc/xstartup.turbovnc) is loading a different window manager than the startup script that TightVNC and TigerVNC use (~/.vnc/xstartup). You could try copying ~/.vnc/xstartup to ~/.vnc/xstartup.turbovnc. If that works, then please send me the xstartup script so I can figure out why it works. (2) The next thing I'd try is to launch the TurboVNC server with an argument of "-norender", which will disable the RENDER extension (TightVNC didn't have that extension.) > I'm using the prebuilt Xvnc from this package: > > turbovnc-1.1.95.tar.gz I'm a little confused, since our distribution of turbovnc-1.1.95.tar.gz is a source package and has no pre-built Xvnc binary. ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
