Oddly, I can no longer reproduce the issue whereby it was sending too much data. Either I was doing something stupid, or the problem just went away. The profile now is showing what I initially suspected, which is that, with the ComparingUpdateTracker turned off, the image getter is accounting for about 15% of the performance. I'm going to see if I can figure out how to temporarily lock and directly access the underlying framebuffer to get rid of that overhead.
On 8/15/11 6:54 AM, Peter Åstrand wrote: > >> 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. > > I agree, this is strange. Are you testing with the same version of the > Xserver etc? Are all/most GC hook operations called twice, or just some > of them? ------------------------------------------------------------------------------ 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
