Den 2009-05-04 13:49 skrev Pierre Ossman: > 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> > > 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.
I think "must not" is out of line in this paragraph, you even describe servers not doing it that way in the ending notes... The correct thing to say is "should not" IMHO. *snip* > +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. Are you really certain about how you should interpret the fb-changing rects leading up to the DesktopSize rect? There are bound to exist servers that in some cases push out some pending totally superfluous "dirty" rects before a final DesktopSize rect in an update. Heck, if you combine with LastRect, the server might not even be aware of the fact that it is about to send a DesktopSize rect at the end of the update when it starts to generate it. In my reading of the spec, I have always thought that those initial rects where supposed to be applied before the change in desktop size, but maybe that's just me. I wouldn't bet on that though. Buttom line is, the only sensible thing for a client to do in response to a DesktopSize rect is to always make a non-incremental FBU request in order to not rely on some server-specific quirk. It can't know if the server has retained the fb or not, so it has to make the non-incr FBU request to get to a known state. Cheers, Peter ------------------------------------------------------------------------------ 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
