On Tue, 31 Mar 2009 16:08:51 +0200 Pierre Ossman <oss...@cendio.se> wrote:
> I've committed a optimisation for the RGB24 to RGB32 conversion (the > most common one on the client). It heavily reduces the cost of > conversion, but it is still significant and complete removal would > still be a big win. > After I did this little hack, the client's CPU was no longer the bottle neck, but instead the fact that the client and server will be working in tandem, waiting for each other. To remedy this, I modified the client to send a new FUR when it started decoding the previous FU, instead of when it was done decoding. This got the system back to being CPU bound. The downside though is that the X11 loop is never given any time now, so the client is entirely unresponsive. :) The last part can easily be fixed, but I'm curious as to how TurboVNC solves this. Darrell, care to enlighten us as to how the TurboVNC client handles update requests? I believe you mentioned that you had made an improvement in that area. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
