On 3/11/13 3:53 AM, Peter Åstrand wrote: > I don't want to restart the debate, but just point out to the TigerVNC > audience that we have a different view on a few things:
If you don't want to restart the debate, then don't restart the debate. Nothing I said in my previous message was anything that I hadn't already said before. I was careful to present the issue in as balanced a manner as I could. > The TigerVNC 3D performance is very good, so have certainly not "killed > 3D". Remember, one of the reasons why we started the TigerVNC project > was to bring TurboVNC-like performance to a more modern code base and X > server platform. Yes, and I spent many hundreds of hours making that happen. But then you would do something like changing the deferred update timer value, which effectively brought the high-speed network performance back down to 60% of TurboVNC's and effectively nullified my work. Then I would have to engage in a protracted battle to get you and Pierre to revert the change. Similar battle regarding the comparing update tracker. As far as a "modern" code base, I presented the pros and cons of that in my previous message. TurboVNC uses an in-tree X server code base because it gives us 100% control over the quality of the solution. As the person who used to maintain the "cross-compatible" build of TigerVNC, I'm in a very good position to describe the issues associated with that approach. If someone discovers an X server bug in TurboVNC, we can put Xvnc into gdb, find the bug, and check in a patch to our own repository. Trying to fix bugs in a separately-built X.org code base is a completely different matter. This is why I say that TigerVNC is "in its element" as an O/S-supplied solution. If you're building it, for instance, on a newer Red Hat/Fedora platform, then Red Hat has already done a lot of the work of debugging the X server for you, and they also provide debug symbols for it and its numerous dependencies. I am not trying to say that TurboVNC is inherently a "better" solution. I'm just saying it's a different approach. I would not have thought that that was a controversial statement. > In our view, the debate was rather about 2D and bandwidth. We argued > that - by default - we could accept a minor 3D performance penalty, if > the 2D and bandwidth situation was significantly improved. For customers > which always connects through a high speed LAN (never uses remote > connections), a simple configuration flag could be used to indicate this. Peter, I have said all along that if you or anyone else wants to do the same research as I did and come up with encoding methods that are more suitable for a "general-purpose" VNC solution, then the research tools are open and available for you to use. What you will need to do is perform a similar procedure to the one described here: http://www.virtualgl.org/pmwiki/uploads/About/tighttoturbo.pdf. The original research leading to the TurboVNC encoding methods (that TigerVNC now partly uses) was conducted while I was an employee at Sun, but since then, I have had an opportunity to revisit the research in the process of replacing the TightVNC encoder in libvncserver with the TurboVNC encoder. What we discovered during that process was that, in fact, it's possible to use the TurboVNC encoding methods to encode 2D applications about as "tightly" as the tightest "usable" mode in TightVNC. However, this "TightVNC replacement" mode (which is provided in TurboVNC as an undocumented Compression Level 9) doesn't really provide more than 10-20% bandwidth savings over Compression Level 2. Really, the high-numbered compression levels in TightVNC and TigerVNC are largely useless. They add CPU time without significantly reducing bandwidth for any workloads we tested. One of the differing approaches in TurboVNC and TigerVNC is that TurboVNC does not expose any mode that has not been proven to provide broadly-applicable performance gains. My point is that there has been *a lot* of performance research conducted outside the scope of TigerVNC. In addition to the encoding method research described above, over the past year I have spent many hours developing benchmark methodologies for the VNC viewer, which are also based on RFB session captures. Our research is ongoing and constantly feeds into TurboVNC. TigerVNC only contains a snapshot of the research as of two years ago. You and Pierre have, at times, been very quick to dismiss this research in favor of some quick & dirty benchmarks that you conducted that show certain 2D applications performing a bit faster with certain things enabled or disabled in TigerVNC. You have, on at least 2 occasions, introduced changes to TigerVNC based on those quick & dirty benchmarks without performing due diligence to see how the changes affected other apps (including 3D apps.) These changes, in the aggregate, nullified a lot of the hard-fought gains that I brought in based on the TurboVNC research. I've spent my entire career figuring out how to make applications run faster. If you are genuinely interested in giving TigerVNC "TurboVNC-like" performance, then your choices at this point are to either keep abreast of my research and adopt it or conduct your own research of similar quality. You can't say you're a "TurboVNC-like" solution when you aren't putting forth the same effort to maximize and maintain the performance of your solution for the types of apps that we focus on. You yourself were the one who suggested that TigerVNC should have a "3D app" mode, because you didn't feel that the performance goals of the TigerVNC Project and the VirtualGL Project were reconcilable in the long term. So you've contradicted your own point. If TigerVNC were truly "TurboVNC-like", then such a mode would not be necessary. "By default" is the operative phrase in your reply above. It is only because I pushed back -- hard -- that TigerVNC has a mode (Compression Level 1) that produces optimum high-speed network performance for 3D apps without requiring a special server setting. You and Pierre really wanted the comparing update tracker (which drops performance by about 10-15% when it is enabled on a high-speed network) to be enabled in all modes by default. What we ended up with in TigerVNC 1.2 was a compromise, but the compromise was so difficult to achieve that it made me realize that, while it might be technically possible to merge TurboVNC and TigerVNC, it would never be politically possible. >> The solutions were and are just too different. > > We disagree, we believe that the solutions are very much alike. You guys can't have your cake and eat it, too. You can't claim to be a TurboVNC replacement when you fought me tooth and nail for almost every TurboVNC feature I tried to port into TigerVNC and effectively drove me out of the project by arguing almost every idea I ever had into the ground, even stuff that should not have been controversial. TigerVNC, as a project, does not have the necessary QA and release processes in place to produce an enterprise-quality product. Cendio probably adds those processes downstream, but since your processes are internal and not exposed to the community, they don't benefit the community. Let's run down the list, shall we? Apart from having to fight you on performance issues (above), here are the other things I can think of off the top of my head that I've gotten push-back on: -- Automatic lossless refresh -- Multi-threaded encoding and decoding -- Auth extensions (more specifically, a global authentication configuration file) -- The rfbTightNoZlib extension -- Fixing the double buffering in the TigerVNC viewer (TigerVNC will sometimes interrupt a redraw, which produces tearing artifacts on slower connections.) (for the last two, I submitted a patch that should have been a no-brainer.) There are others, but you get the idea. TurboVNC is a solution that focuses on the needs of 3D apps, QED. TigerVNC cannot claim to have this same focus when you have, on many occasions, fought against the research that makes TurboVNC what it is. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Tigervnc-users mailing list Tigervnc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-users
