On 12/13/07, Peter Rosin <[EMAIL PROTECTED]> wrote: > 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 James, VNC non-free edition doesn't have this limitation, since it doesn't have Refresh Screen function? Or it implements a new RFB protocol that has not been published? What scheme that the non-free edition use? While the RFB protocol spec doesn't contain any mechanism or any guides to cope with this problem, can you reveal the guides that is used to solve this problem in non-free edition? > You shouldn't need to use > Refresh Screen, in general. 1. Although the user doesn't need to use Refresh Screen function, but the thin client that lost its visual framebuffer (and no backup copy, as stated by Peter) still need to refresh the screen by itself. 2. Although the pixfmt isn't changed by user, but it may be automatically changed by the client itself, when the traffic quality change. 3. What if the client lost its visual framebuffer, and the traffic quality has changed, simultaneously? The problem still exists in this case. > > 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 I agree with this. The thin client with no backup copy of its framebuffer will frequently need to refresh the screen by sending non-incremental update request. It may possibly change the pixfmt on the fly, when network quality change. This is the problem of RFB protocol, that the client can't change pixfmt and request framebuffer update at the same time, otherwise, it will be in an unstable state. > 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? I think the best way is to define it in the core of the new version of RFB protocol. To just add the extension into existing RFB protocol, doesn't make the other implementation of VNC client/server to aware of the important of this extension. The new version must state that the client should rely on the new pixfmt only when the server explicitly confirm that the pixfmt has been changed. The client should NOT expect new pixfmt, just because it has sent the setPixFmt to the server. P.S. I just have found that I can't reproduce this bug (using the same method) when connecting to Xvnc 3.3.7. I don't know why, but I will investigate for it. _______________________________________________ VNC-List mailing list [email protected] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
