Peter, It is a limitation of the RFB 3.x protocol, which requires that update requests are required to be matched 1-to-1 by framebuffer updates, although this isn't strictly required if the pixel format isn't going to change. It therefore affects VNC Free Edition & software based upon it.
Cheers, -- Wez @ RealVNC Ltd > -----Original Message----- > From: Peter Rosin [mailto:[EMAIL PROTECTED] > Sent: 13 December 2007 12:16 > 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 Thu, Dec 13, 2007 at 10:09:07AM -0000, James Weatherall wrote: > > 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. > > Hi Wez, > > I'm not talking about the VNC Free Edition system, I'm > talking about the protocol and what clients should do. > > The problem is that if a client wants to do a pixfmt change > it has to wait for an outstanding FramebufferUpdateRequest to > be satisfied by a FramebufferUpdate. That's the only way be > sure that the next requested FramebufferUpdate is in the > expected pixfmt, as I'm sure you understand. Hmmm, perhaps > not the only way, see below... > > The problem is that you seem to think that this is only a > problem when using the Refresh Screen function in VNC Free > Edition, while my position is that it is a generic protocol > problem which puts unfortunate limitations on clients. So, if > the following is true: > > 1. the client has an outstanding FramebufferUpdateRequest 2. > the client has lost its visual framebuffer 3. the client > screen depth has changed (likely to cause 2) 4. the client > doesn't have a backup copy of the framebuffer 5. the server > doesn't have any updates for a long time > > then the client will show a blank screen for "an indefinite > period" as the spec puts it. It has to wait for the server > before it can refresh with the new pixfmt. I think it is very > valid for the client to want to change pixfmt and get an update *now*. > > Sure, it can send extra non-incremntal > FramebufferUpdateRequests and then try to sort out when it > can be sure that no more FramebufferUpdates are coming down > the wire, but that is complex. > > The proposed solution in my previous mail is just so much > simpler, and keeps in line with "implementing a client is > made as simple as possible," again from the spec. Just > compare to this complex alternative when you want to change > pixfmt and get an update *now*: > > 1. Send a non-incremental FramebufferUpdateRequest for a small area. > 2. Wait for a FramebufferUpdate. > 3. If the update does not contain the requested area from 1, goto 7. > 4. Send a non-incremental FramebufferUpdateRequest for another > (non-intersecting) small area. > 5. Wait for a FramebufferUpdate. > 6. If the update does contain the requested area from 4, goto 8. > 7. Wait for a FramebufferUpdate. > 8. Send SetPixelFormat. > 9. Send full non-incremental FrameBufferUpdateRequest. > > Is there a simpler way to work around this without protocol > additions such as new pseudo-encodings? > > Cheers, > Peter > _______________________________________________ VNC-List mailing list [email protected] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
