On Tue, 31 Mar 2009 12:26:36 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> Essentially, it moves the sending of the next FUR into the X11 or > Windows message loop. So, when the RFB FU is received by the client, it > immediately triggers either an X11 or a Windows custom event message > with the necessary information to send a new FUR. > > You can see the relevant changes to vncviewer with the following diffs > (bearing in mind that this is based on the older TightVNC code): > > http://virtualgl.cvs.sourceforge.net/viewvc/virtualgl/vnc/vnc_unixsrc/vncviewer/desktop.c?r1=1.4&r2=1.5 > http://virtualgl.cvs.sourceforge.net/viewvc/virtualgl/vnc/vnc_unixsrc/vncviewer/rfbproto.c?r1=1.7&r2=1.8 > Hmmm... That should have no effect on a high-speed network (where the X11 loop will not get any CPU time until the FU is done), or very close to the same effect my hack did if there are gaps in the incoming RFB data. It does sidestep my problem with the X11 loop not getting any attention though... > Doing just this improved the performance on broadband but caused > performance to be worse in LAN environments. In order to return the LAN > performance to its original level, I had to also set the deferred update > timer on the server to 1 ms. > Odd. Did you figure out why it got worse? It should have had no effect either way on a fast network. 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
