Re: [Qemu-devel] [PATCH] vnc: shared buffer: skip some optimizations.

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

Gerd Hoffmann wrote:

> The trouble spot is here:  The guest might have updated the screen
> between (b) and (c).  This will cause the vnc clients view of the screen
> content become inconsistent with old_data.  On the next update round (b)
> will stop working correctly due to that.


Even if old_data becomes inconsistent with the client's screen, the
worst that can happen is that (b) will set as 'to send' framebuffer
areas that have already been sent. Is that so bad? Does it really cause
visible problems? Intuitively I would think not, but I may be wrong.

 
> What my patch does in terms of the old code is make step (c) use
> old_data instead of the guest-visible framebuffer.  I didn't like
> stacking hacks on hacks like this though, so I decided to explicitly
> name the two surfaces.
> 
> You still could get away with just one dirty bitmap for both surfaces.
> Having two bitmaps IMHO makes the code more readable though.  It also
> allows killing the memset(old_data,42,size) hack for forced client
> updates (see framebuffer_update_request()).  An -- in preparation for
> the future -- it makes the vnc code a bit more thread-friendly.  Guest
> screen updating (aka vnc_update()) can run in parallel with encoding
> updates for the guest (i.e. step (c)).

I agree that your patch makes the code more readable, I only am not sure
if it fixes a real world problem.