The implementation of the DesktopSize (also called NewFBSize) pseudo-encoding differs a bit between VNC families. This tries to document a behaviour that works in the majority of the implementations.
Signed-off-by: Pierre Ossman <oss...@cendio.se> -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
Index: rfbproto.rst =================================================================== --- rfbproto.rst (revision 3796) +++ rfbproto.rst (working copy) @@ -1310,10 +1310,41 @@ A client which requests the *DesktopSize* pseudo-encoding is declaring that it is capable of coping with a change in the framebuffer width -and/or height. The server changes the desktop size by sending a -pseudo-rectangle with the *DesktopSize* pseudo-encoding as the last -rectangle in an update. The pseudo-rectangle's *x-position* and -*y-position* are ignored, and *width* and *height* indicate the new -width and height of the framebuffer. There is no further data -associated with the pseudo-rectangle. +and/or height. +The server changes the desktop size by sending a pseudo-rectangle with +the *DesktopSize* pseudo-encoding. The update containing the +pseudo-rectangle must not contain any rectangles that change the +framebuffer data. + +The pseudo-rectangle's *x-position* and *y-position* are ignored, and +*width* and *height* indicate the new width and height of the +framebuffer. There is no further data associated with the +pseudo-rectangle. + +The old framebuffer data does not need to be preserved when the +framebuffer changes size. The server must therefore not use any +encoding that relies on the previous contents of the framebuffer. + +The principle of one framebuffer update being a transition from one +valid state to another does not hold for updates with the *DesktopSize* +pseudo-rectangle as the framebuffer contents will temporarily be +undefined. Clients should try to handle this gracefully, e.g. by +showing a black framebuffer or delay the screen update until a proper +update of the framebuffer contents has been received. + +Note that some early implementations require the *DesktopSize* +pseudo-rectangle to be the very last rectangle in an update. Servers +should make every effort to support these. + +Also note that some servers send framebuffer data changes before the +*DesktopSize* pseudo-rectangle. A client that wishes to be compatible +with these servers must either retain the framebuffer contents as the +dimensions change, or make sure that the next +*FrameBufferUpdateRequest* has *incremental* set to zero. + +As some clients send a *FramebufferUpdateRequest* with *incremental* +set to zero, because of the issue above, the server must not send a new +*DesktopSize* pseudo-rectangle in the following update. Doing so would +make the system go into an infinite loop. +
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
