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 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. Pierre Ossman wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
