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 -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
