|
Sorry to see you go. I hated to see all the static on the list the
last little while. Had hoped it had all calmed back down. I
understand that sometimes it does not work that way. I want to
thank you for all your contributions. I know that amount of work
you put into the encoder and CMake build system. Thank you for that
and working thru my bug reports. Robert On 03/09/2012 07:10 PM, 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. DRC ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel --
Robert Goley
FOSS Implementation Specialist Toll Free: (800) 338-4984 Local: (770) 479-7933 Fax: (770) 479-4076 www.openrda.com Helping local schools and governments make a difference.
P Go Green!
Please try not to print this e-mail unless you really need
to.
|
------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
