From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LjA4h-0007rE-GL for qemu-devel@nongnu.org; Mon, 16 Mar 2009 06:29:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LjA4d-0007qE-7y for qemu-devel@nongnu.org; Mon, 16 Mar 2009 06:29:39 -0400 Received: from [199.232.76.173] (port=54949 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LjA4d-0007qB-4v for qemu-devel@nongnu.org; Mon, 16 Mar 2009 06:29:35 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:63342) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LjA4c-0006r3-ME for qemu-devel@nongnu.org; Mon, 16 Mar 2009 06:29:34 -0400 Message-ID: <49BE299F.1030802@eu.citrix.com> Date: Mon, 16 Mar 2009 10:27:43 +0000 From: Stefano Stabellini 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> In-Reply-To: <49BE0F50.5000009@redhat.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: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" 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.