On Tue, 31 Mar 2009 14:44:42 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> 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. > I've had a look at the current code, and the behaviour is still there. The fundamental problem is that deferred updates are handled over in Xvnc, not in librfb. I think we need to have all handling in librfb to have some sanity in the behaviour. I think this can wait until after the release though and I've also added an entry in SF's tracker. 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
