From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LjAeq-0002HC-Fj for qemu-devel@nongnu.org; Mon, 16 Mar 2009 07:07:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LjAel-0002Fi-Ek for qemu-devel@nongnu.org; Mon, 16 Mar 2009 07:06:59 -0400 Received: from [199.232.76.173] (port=55502 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LjAel-0002Ff-Bs for qemu-devel@nongnu.org; Mon, 16 Mar 2009 07:06:55 -0400 Received: from mx2.redhat.com ([66.187.237.31]:36184) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LjAek-00034d-Qi for qemu-devel@nongnu.org; Mon, 16 Mar 2009 07:06:55 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2GB6rP2021147 for ; Mon, 16 Mar 2009 07:06:53 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n2GB6sAF012252 for ; Mon, 16 Mar 2009 07:06:54 -0400 Received: from zweiblum.home.kraxel.org (vpn-10-108.str.redhat.com [10.32.10.108]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n2GB6q0m008219 for ; Mon, 16 Mar 2009 07:06:53 -0400 Message-ID: <49BE32CB.70405@redhat.com> Date: Mon, 16 Mar 2009 12:06:51 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] vnc: shared buffer: skip some optimizations. References: <49B7CE21.4030104@redhat.com> <49B7DC25.6010500@codemonkey.ws> <49B9697C.5020607@redhat.com> <49BA4B9B.7040208@eu.citrix.com> <49BE0F50.5000009@redhat.com> <49BE299F.1030802@eu.citrix.com> In-Reply-To: <49BE299F.1030802@eu.citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Stefano Stabellini wrote: > 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? (b) doesn't set the 'to send' bit. It clears the 'to send' bit for screen areas which are not modified. You have two possible effects: * screen update is sent twice. * screen update is *not* sent. The second causes persistent screen corruptions, it is not fixed up by the next refresh. Wanna have a screen shot? cheers, Gerd