My somewhat long-winded explanation is in Section 5.2 of this report: http://www.virtualgl.org/pmwiki/uploads/About/vglperf21.pdf
This is based on probing around in the code, and I have no doubt that my understanding is faulty in places. However, at least in the old TightVNC code (I have no idea if TigerVNC works the same way), if a FUR for frame 1 was received by the server and the framebuffer hadn't been modified since the FU for frame 0, then FUR1 was deferred. Thus, when the client was modified to send back FUR1 immediately upon receiving FU0, then this increased the likelihood that the server would receive FUR1 before the application had updated the framebuffer. Recalling that I'm dealing mainly with 3D applications that do mainly continuous full-screen updates, essentially this led to a condition in which every FU was deferred, and thus 40 ms was being added to every frame. Pierre Ossman wrote: > 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... > > Odd. Did you figure out why it got worse? It should have had no effect > either way on a fast network. > > Rgds > ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
