From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcAON-0004zx-GB for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:52:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcAOL-0004yh-9Z for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:52:46 -0400 Received: from [199.232.76.173] (port=36102 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcAOK-0004yc-Nh for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:52:44 -0400 Received: from an-out-0708.google.com ([209.85.132.245]:55616) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcAOK-0003ni-CD for qemu-devel@nongnu.org; Sat, 06 Sep 2008 22:52:44 -0400 Received: by an-out-0708.google.com with SMTP id d18so163467and.130 for ; Sat, 06 Sep 2008 19:52:43 -0700 (PDT) Message-ID: <48C341CA.30002@codemonkey.ws> Date: Sat, 06 Sep 2008 21:51:54 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0 of 3] vnc and vga improvements References: <48B6C8FB.9090106@eu.citrix.com> <48B7057B.2050203@codemonkey.ws> <48B7C6A7.2050706@redhat.com> In-Reply-To: <48B7C6A7.2050706@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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 Gerd Hoffmann wrote: > Anthony Liguori wrote: > >> Stefano Stabellini wrote: >> >> I have mixed feelings about this. On the one hand, reducing the copying >> is a good thing. On the other hand, we pretty much make it impossible >> to ever support multiple clients. >> > > Getting rid of the color space conversions is a good thing, even in case > we can't drop the separate buffers and the memcpys. Right now the vnc > server runs at 32bit unconditionally. Having it run at 16bpp in case > the guest uses 16bpp is still a win because we (a) have to handle less > memory and (b) can to a straight copy instead of a pixel conversion. > It's not as big of a win as it seems as there is only one client that can handle this ATM :-) > And maybe the buffer sharing can be implemented in a way that we can > turn it on and off at runtime? So the common case of at most one client > can run with buffer sharing, otherwise we copy to per-client buffers? > Yes, I would like this. I haven't yet looked closely at the patches, but if this is the case, I would be inclined to apply them. Regards, Anthony Liguori > I'm not a vnc protocol expert though. > > Looking at the patches, it seems buffer sharing is optional already > (usage depending on the color depth right now it seems). > > cheers, > Gerd > > > > >