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. > Ah, I see. That makes sense. I don't know how the current deferred update system is implemented, but I'll have a look. The behaviour of sending changed areas immediately on a FUR is a bug IMO and should be fixed if it's there in the current code base. The way deferred updates is documented, it's supposed to aggregate changes over a certain time. That should mean that you cannot get updates at a faster rate than that timer. Does everyone agree with that assessment? 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
