pixel format is out of sync, after refreshing and suddenly changing pixel format

[James Weatherall]

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:peda "at" lysator.liu.se] 
> Sent: 13 December 2007 12:16
> To: James Weatherall
> Cc: 'Anon Sricharoenchai'; vnc-list "at" realvnc.com; 
> vnc-tight-devel "at" lists.sourceforge.net
> 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
>