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

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

Gerd Hoffmann wrote:

> Sending screen updates to the client will be done using the server
> surface + dirty map only, so the guest updating the screen in parallel
> can't cause trouble here.

Could you please explain an example of trouble caused by sich situations?

Given A, B and C three different points in time with A < B < C,
currently what we are doing is:

A) getting the guest dirty map

B) filtering the guest dirty map using memcmp with the server surface
(called old_data in the current code), however the dirty map could be
inconsistent with the framebuffer because was set in A

C) sending updates to the client from the guest surface based on the
dirty map, however the dirty map is inconsistent because it was set in A
and filtered in B

In any case we get the new dirty map next iteration and it will include
all the possible changes that happened after A, possibly already sent to
the client inadvertently in C.

---

with your patch we have:

A) getting the guest dirty map

B) setting the server dirty map using the guest dirty map and memcmp
with the server surface, however the dirty map could be inconsistent
with the guest framebuffer because was set in A

C) sending updates to the client from the server surface

In any case we get the new dirty map next iteration and it will include
all the possible changes that happened after A, possibly already sent to
the client inadvertently in C.

---

If your goal is to remove possible update incosistencies, your patch
certainly removes the one in C, but not the one in B.

If your goal is to send the most updated version of the framebuffer to
the guest ASAP, the current code is better at it.