From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Qemu vnc color depth Date: Mon, 11 Feb 2008 11:37:40 +0000 Message-ID: <47B03384.6030109@eu.citrix.com> References: <47B02F63.4010406@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org James Harper wrote: >> The basic idea is that the vnc client is the one that should do the >> colour conversion, if necessary. > > What impact, if any, does this have on the bandwidth required for the > VNC connection? I've been using VNC to access HVM Xen clients over a > 512k link lately and it's only barely acceptable. My color level is set > to 'Low (64 Colors)'. If the client is doing the conversion then doesn't > this mean that the server has to transmit 16/24/32 bits of color > information to the client, rather than 6? > > Or more likely, maybe I don't understand the implications of your patch > :) > It is the opposite :) Now most vnc clients run on 32 bpp display, so they automatically ask for 32 bpp connections to the server, even if the guest is using 16 bpp. This is a waste of bandwidth. Using my patch together with the right configuration of your vnc client you can just use the bandwidth needed to preserve the colour depth resolution of the guest and nothing more.