Changing pixelformat on the fly

[James Weatherall]

Peter,

The problem in your diagram is that the server for some reason sends a
second unsolicited Framebuffer Update, without waiting for a request from
the viewer.  No RFB-compliant server will ever do this.
The RFB 3.8 protocol explicitly states that there will be exactly one
FramebufferUpdate per FramebufferUpdateRequest, and that there should only
ever be one outstanding FramebufferUpdateRequest at any time.  This is what
the standard VNC viewer & server implement, so they will behave correctly
when the format changes.
The most likely cause of problems is that whatever "modifications" you have
made to the viewer alter the semantics of the FramebufferUpdateRequest part
of the protocol - I doubt very much that it's a problem in TightVNC.

Regards,

Wez @ RealVNC Ltd.


> I believe I've discovered a problem with the VNC protocol, related to 
> changing the pixel format on the fly. Take a look at this chart:
> 
> FUR=FramebufferUpdateRequest
> FU=FramebufferUpdate
> SPF=SetPixelFormat
> 
> Client			Server
> ------------------------------
> FUR sent
> 			FUR recieved
> 			FU1 sent
> FU1 recieved
> SPF sent
> 			(deferred) FU2 sent
> 			SPF recieved
> FU2 recieved
> 
> As you can see, FU2 is sent *before* the server has recieved 
> the SPF, but 
> on the client, FU2 is recieved *after* the SPF has been sent. 
> Bang! The 
> client inteprets the FU according to the new pixel format, 
> but the FU is 
> in fact using the old pixel format. Then everything gets out 
> of sync, and 
> the client crashes.