From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZ0el-00057f-Ov for qemu-devel@nongnu.org; Fri, 29 Aug 2008 05:52:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZ0eh-00054A-QK for qemu-devel@nongnu.org; Fri, 29 Aug 2008 05:52:39 -0400 Received: from [199.232.76.173] (port=50337 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZ0eh-00053k-IS for qemu-devel@nongnu.org; Fri, 29 Aug 2008 05:52:35 -0400 Received: from mx2.redhat.com ([66.187.237.31]:50813) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KZ0eh-0003qB-1l for qemu-devel@nongnu.org; Fri, 29 Aug 2008 05:52:35 -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 m7T9pr5A010689 for ; Fri, 29 Aug 2008 05:52:13 -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 m7T9pgA2006953 for ; Fri, 29 Aug 2008 05:51:42 -0400 Received: from zweiblum.travel.kraxel.org (vpn-4-160.str.redhat.com [10.32.4.160]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m7T9pZR1025158 for ; Fri, 29 Aug 2008 05:51:36 -0400 Message-ID: <48B7C6A7.2050706@redhat.com> Date: Fri, 29 Aug 2008 11:51:35 +0200 From: Gerd Hoffmann 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> In-Reply-To: <48B7057B.2050203@codemonkey.ws> 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 Anthony Liguori wrote: > Stefano Stabellini wrote: >> Hi all, >> This is a three patch series coming from xen-unstable to improve vnc >> and vga performances. >> >> The first patch implements dynamic colour depth changes in vnc.c: >> this way the vnc server can change its own internal colour depth at run >> time to follow any guest resolution change. >> >> The second patch implements the WMVi vnc extension in the qemu vnc >> server, so that we can also notify a vnc client when we change >> internal colour depth and offload any possible colour conversion to the >> client. >> >> The third patch implements sharing of the display pixel buffer between >> vnc.c and vga.c, in order to save a lot of memcpy's. >> >> The idea is that vnc.c (and in the near future sdl.c too) strictly >> follows the guest display resolution and notifies the client of any >> change. As a consequence we can save two colour conversions: one between >> vga and vnc, another one between the vnc server and the vnc client. >> > > 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. 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? 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