On Wed, 22 Apr 2009 16:34:51 +0200 Pierre Ossman <oss...@cendio.se> wrote:
> - Clarify DesktopSize behaviour based on a survey of the major VNC > implementations. Thinking more about this, I now believe that the RealVNC implementation of DesktopSize is broken and incompatible with the earlier implementations like tight, as well as gtk-vnc. The reason is that those clients drop their framebuffer when they get a DesktopSize message, but they assume that the server will send the entire screen on the next update (even with an incremental update request). Now the RealVNC server doesn't do this since screen updates that have happened after the framebuffer resize will be sent in the same update as the DesktopSize rectangle, but before it as the DesktopSize rectangle is always delayed to the end of the update. The end result is that the clients will discard that data, but the server will believe that the clients already have the current state of those regions. 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
------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
