On Fri, Mar 09, 2012 at 06:10:22PM -0600, DRC wrote: > Hi, all. Since I have seen the 1.2.0 code base (which contains all of > my codec optimization work) through to its release, I have decided that > this is a good time to step down as maintainer of the TigerVNC Project > and return my focus to TurboVNC. I will continue to monitor this > mailing list and participate in discussions as I am able, but I won't be > supplying cross-compatible builds or doing any major testing or > development work beyond 1.2.0 unless specifically contracted. > > I've contributed a lot of effort to TigerVNC over the past few years, > about half of which was pro bono, with the strategy being to eventually > evolve TigerVNC into something that could replace TurboVNC. It was a > noble experiment, but over the last 6 months, I've come to realize that > the projects are fundamentally different in their approaches, and trying > to turn TigerVNC into TurboVNC 2.0 is in many ways like trying to fit a > square peg into a round hole. > > Part of this is just a basic difference in development philosophy. > TurboVNC's philosophy has always been to maximize performance for > applications that need maximum performance while still retaining > adequate performance for applications that are less > performance-critical. The TurboVNC encoder (which, at least for the > moment, shares the same basic behavior as the TigerVNC encoder) may not > provide the tightest encoding for OpenOffice, for instance, but it is > certainly tighter than most other VNC solutions, and it does provide the > tightest and fastest encoding for apps like CATIA and Google Earth and > MPlayer that really need it. However, it seems to me that the project > goals regarding performance have been somewhat schizophrenic of late. > As soon as I was able to make the TigerVNC codec perform on parity with > the TurboVNC codec (something which was a stated goal of the project for > two years), the project shifted in favor of increasing performance for > non-performance-critical applications, thus effectively nullifying a lot > of the work I did. We were able to compromise for 1.2, retaining a > non-default mode of operation (Compression Level 1) that provides > TurboVNC-like levels of performance and can be easily configured from > the viewer, but I had to fight tooth and nail for this. I'm tired of > fighting. The data is there for anyone to see and reproduce, and the > methodologies used to obtain it are easily accessible and can be applied > to other applications that are less 3D-focused, if that is the desire. > If such an analysis is performed, and the TigerVNC Project decides that > a new set of defaults are necessary to maximize performance for the apps > that TigerVNC users care about, then fantastic. However, such decisions > need to be based on thorough, scientific analysis that takes into > account many different applications, not just one. > > Further, TigerVNC is really designed to be built against a > distribution-supplied X code base. The idea is that the distribution > vendor takes care of debugging and maintaining the X server, and since > Xvnc is built to mimic it, it should encounter minimal compatibility > problems on that platform. Of course, as you all well know, the > disadvantages to that approach are that it requires a different build > procedure for every platform, so it's somewhat difficult for developers > to come up to speed with our server code unless they have some fairly > deep knowledge of their O/S distribution. It is also somewhat difficult > to debug issues in the server, since they are often very > platform-specific. Our attempt to work around this was to create a > "cross-compatible" build process that uses a known good version of > X.org, GnuTLS, gettext, etc. However, that is not without its issues, > not the least of which is that it requires building the complete > infrastructure to all of the above, which is a very long process. > Further, since few developers build the code that way (even Cendio does > not use build-xorg, AFAIK), it puts the responsibility for debugging any > X-related or build-related issues in the cross-compatible build largely > on my shoulders. Diagnosing issues with such a large X server > infrastructure that is built entirely out of tree is exceedingly > difficult, and fixing them even moreso (requiring generally upgrading > some of the components, which creates all new issues.) Ultimately, if > I'm going to be in the position of maintaining my own X code base, I'd > rather maintain one that I am familiar with and which contains only the > minimal code necessary to build a VNC server. Even though using an > in-tree X server has its drawbacks-- mainly, it is not future-proof-- it > puts me in full control over the quality of the project, something which > I never felt I could achieve with TigerVNC. > > Thus, I personally think that the best way forward for this project is > for me to stop trying to make it into something it's not. TigerVNC is a > great general-purpose distributor-maintained VNC release for Linux > servers, far exceeding TightVNC and RealVNC, but it is not a very > easily-maintained standalone cross-compatible product, and it can't > really be made into one without basically re-architecting it. Doing > that would require either an in-project or an out-of-project fork, and > at this point, the prevailing desire within the VirtualGL community is > just to go forward with TurboVNC instead. > > I wish you all the best of luck.
Since you were the most active developer, this is very unfortunate information for the entire TigerVNC project. I wasn't involved in development recently but I admit the main goals of TigerVNC and TurboVNC are different (at least from Xvnc perspective, which I mainly worked on). May I ask you if you have any scripts which you used for building release/pre-release versions of TigerVNC? I would be glad if you share them. I wish you the best luck with TurboVNC+VirtualGL. Regards, Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
