2007/10/3, Daniel P. Berrange <address@hidden>:
The memset calls in that patch are bogus & not correctly fixing the buffer
update problem. You're merely setting the 'old data' to have pixel value
42 - if the guest OS framebuffer happens to also have aras with pixel value
of 42 too, the frame buffer will still not correctly update. The root
problem is overly-aggressive update minimization logic in vnc_update_client.
This is in turn flawed beause the dirty_row aray is trying to encode two
separate concepts - areas which are dirty, and areas which need to be
sent to the client. The latter are a superset of the former, but the code
in vnc_update_client minimizes based on dirtiness, so updates will get
missed out. Setting the old data to 42 merely changes which areas will get
missed updates.
Agreed. I just used the same hack that is scattered around several other places to make a patch quickly.
The QEMU code in Xen has added a update_row field, separate from the dirty_row
field. Thus after a resize it can update the entire framebuffer, regardless
of whether QEMU's copy of the framebuffer is dirty wrt to the guest copy.
I think that VNC server needs a deep rework, as several qemu
related projects have done, but meanwhile correcting bugs with small
non-intrusive patches may be the way to go.
Edu.