I've already hacked around it, so review the check-in I'm about to make and suggest a better approach, and we'll go from there.
On 8/16/11 3:22 AM, Pierre Ossman wrote: > On Mon, 15 Aug 2011 23:44:24 -0500 > DRC <dcomman...@users.sourceforge.net> wrote: > >> 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. >> > > I might have mentioned this in the past, but I've been thinking that we > should change the encoder API so that it gets both a pointer to the > actual framebuffer, and a conversion object (if needed). This > would solve your case as well as encoders like JPEG where it doesn't > make sense to first convert to the client pixel format. > > We could define that if the conversion object is NULL, then use the raw > framebuffer (instead of providing a dummy converter, which would still > result in copies). > > Rgds ------------------------------------------------------------------------------ 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
