Hi Anon & Peter, The VNC Personal & Enterprise Editions use a new scheme that does not have this limitation.
You won't hit problems with the VNC Free Edition system unless you send multiple outstanding update requests (as is the case when using Refresh Screen), *and* you change the on-the-wire pixel format *after* having done that. Cheers, -- Wez @ RealVNC Ltd > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Rosin > Sent: 13 December 2007 08:43 > To: James Weatherall > Cc: 'Anon Sricharoenchai'; [email protected]; > [EMAIL PROTECTED] > Subject: Re: pixel format is out of sync, after refreshing > and suddenly changing pixel format > > On Wed, Dec 12, 2007 at 01:50:38PM -0000, James Weatherall wrote: > > Hi Anon, > > > > This is a know limitation of the Refresh Screen option in VNC Free > > Edition & VNC Free Edition-based software, which isn't > "safe" to use > > if the VNC Viewer might be changing pixel format at a later point. > > Nice to see it confirmed, I have been thinking about this for > a while but never got around to formulating it in an email. > Also, you seem to hint that this isn't a problem in the > closed sourced versions, can you enlighten us as to how the > problem was resolved, if it has indeed been resolved? > > > You > shouldn't need > > to use Refresh Screen, in general. > > Well, that puts limitations on the client implementation. > Just as an example, imagine a client that draws in a > framebuffer and that the user changes screen resolution (or > that some other application "borrows" the framebuffer). The > client has only one thing to do when it wants to refill the > framebuffer, if it is not allowed to send a full refresh > request: keep a private copy. That isn't too nice, given this > is a thin client protocol. Oh, right, the client can wait for > the next update to be issued as well and then send a full > update request, but that can be a loooong wait. Not too nice either... > > When the solution is a simple as introducing a > pseudo-encoding that gets sent (if requested of course) as an > empty rect before any rect with the new pixfmt is sent, why > not introduce that? > > That would make the protocol more robust, and is easy to implement. > The client has to take care not to have two pixfmt changes on > the wire simultaneously though, but that's not too much of a > limitation. > > (Other solutions are of course also possible, this is just > the first that came to mind) > > Cheers, > Peter > _______________________________________________ > VNC-List mailing list > [email protected] > To remove yourself from the list visit: > http://www.realvnc.com/mailman/listinfo/vnc-list > _______________________________________________ VNC-List mailing list [email protected] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
