On 8/15/11 2:54 AM, Peter Åstrand wrote: > You are probably right that it hasn't been included in any released > version of TightVNC, though. > > The ComparingUpdateTracker is apparently from RealVNC. It's included > even in the 4.0 release. As with most RealVNC code, there are not many > comments about the code. > > One interesting idea is to rewrite the interface to the Xserver to use > the DAMAGE extension. Perhaps that would eliminate this bottleneck.
I can guarantee you that the ComparingUpdateTracker is not in the TightVNC 1.3.x (XFree86-based) code base, because that's the code base TurboVNC is based on as well, and of course that's what I'm using as a performance target for TigerVNC. What I still don't understand is why TigerVNC and RealVNC need this mechanism and why TightVNC and TurboVNC don't. What is the old code base doing differently? Turbo and Tight 1.3.x certainly do not use XDamage, because they don't even provide that extension. Both code bases appear to be hooking into the same GC operations in virtually the same way, and algorithmically doing the same things to trigger an update in response to an X operation. Thus, what I would expect is that, when disabling the ComparingUpdateTracker in TigerVNC, I should get the same behavior as TurboVNC, but I don't. I get duplication of data. ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
