From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LZVBt-00062s-Cc
	for qemu-devel@nongnu.org; Tue, 17 Feb 2009 14:01:09 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LZVBr-00061h-6c
	for qemu-devel@nongnu.org; Tue, 17 Feb 2009 14:01:08 -0500
Received: from [199.232.76.173] (port=58847 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LZVBq-00061Z-RT
	for qemu-devel@nongnu.org; Tue, 17 Feb 2009 14:01:06 -0500
Received: from smtp.citrix.com ([66.165.176.89]:17482)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1LZVBq-0002zb-AE
	for qemu-devel@nongnu.org; Tue, 17 Feb 2009 14:01:06 -0500
Message-ID: <499B0965.9020007@eu.citrix.com>
Date: Tue, 17 Feb 2009 19:00:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: Qemu 2D performance plunges below acceptable
	levels
References: <7fac565a0902150510y1fb01c6awd1dcc3b6e7b8232d@mail.gmail.com>	<7fac565a0902150911u1ed66ef0gc55663d723c76ae4@mail.gmail.com>	<4999407C.5040009@eu.citrix.com>	<49995266.3050707@redhat.com>	<4999913F.3040108@eu.citrix.com>
	<499AF87C.9090703@redhat.com>
In-Reply-To: <499AF87C.9090703@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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

Avi Kivity wrote:

> Stefano Stabellini wrote:
>> Do you see the problem only on X11 remote?
>> How bad is on vnc?
>>   
> 
> vnc regresses in exactly the same way.
> 


This is very strange since the conversions in place for the vnc case are
exactly the same as before.

In your particular case, with a Windows 24bpp, vga.c takes care of
converting the 24bpp format from the emulated videoram to the
DisplaySurface into 32bpp, then vnc reads directly from there.
Before, vnc.c used to set 32bpp in the DisplayState struct and vga.c did
the conversion from whatever format the guest used to 32bpp.
In both case vga.c does the conversion using the same routines in
hw/vga_template.h.

The sdl case is more complicated, but if you are sure that in the vnc
case the slow down is more or less the same, then we can rule out the
color conversions.
Just to be sure, if the guest is in 32bpp do you still see the slow
down? Try in particular with stdvga.