On Mon, 04 May 2009 16:09:24 +0200 Peter Rosin <p...@lysator.liu.se> wrote:
> Den 2009-05-04 13:49 skrev Pierre Ossman: > > +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. > Perhaps. I could only find a single server that implements it this way though, so I was hoping a strong wording would avoid any more. :) > > +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. I suppose there is some value to allow harmless noise before the DesktopSize, but there is a risk that we'll see more people implement it like RealVNC. See below... > > 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. > That would make sense, wouldn't it. :) Unfortunately that's not how RealVNC is implemented. It will send a bunch of updates followed by the DesktopSize, when those updates actually happened after the server resized the framebuffer. This is incompatible with all clients derived from Tight (which is the original implementation of this extension AFAICT) which throw away the framebuffer upon seeing a DesktopSize. > 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. Only UltraVNC sends a non-incr FUR. RealVNC, Tight and gtk-vnc all continue to send incremental FUR (from what I can tell from my reading of the code at least, feel free to object if this is wrong). Unless we want a convoluted specification where the requirements on the server and client do not match up in a symmetrical manner, we need to select on one model and declare the other one a buggy exception. There is the RealVNC model where the client keeps the framebuffer, or the Tight model where the client throws it away. The latter is the simpler and more common one. 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
------------------------------------------------------------------------------ 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
