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
