From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KchZY-0006UW-Vi for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:18:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KchZW-0006To-Rm for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:18:32 -0400 Received: from [199.232.76.173] (port=38788 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KchZW-0006Tl-N9 for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:18:30 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:26563 helo=SMTP.EU.CITRIX.COM) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KchZW-0001lR-Dr for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:18:30 -0400 Message-ID: <48C5349D.60707@eu.citrix.com> Date: Mon, 08 Sep 2008 15:20:13 +0100 From: Stefano Stabellini MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 4 of 5] sdl shared buffer support References: <48BFF045.2030303@eu.citrix.com> <48C4764B.2060008@codemonkey.ws> In-Reply-To: <48C4764B.2060008@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: Anthony Liguori Cc: qemu-devel@nongnu.org Anthony Liguori wrote: > Stefano Stabellini wrote: >> This patch implements shared buffer support in sdl.c. >> It also supports paletted 8 bit colour depths using the >> palette functions provided by the SDL library. >> > > So the theory goes that it's possible with this patch that both surfaces > are hardware surfaces so blitting is fast? The theory goes that SDL blitting and color conversion functions should be as optimized as you can get, and hardware accelerated if your card supports it. Besides I think that offloading blitting and color conversion to a graphic library is a good idea. > In practice, when using X11 > both surfaces are going to be XShmImages so I don't think this is going > to perform any better than the current code. Only the guest framebuffer derived surface is always a software surface, the host window can be an hardware surface (as far as I know). > Do you have any sort of measurements that show an advantage with this > patch? I don't have any numbers, but I'll try to get some. > I sort of think you want the opposite interface. One where the VGA code > uses ds->data directly if the guest ds->data is in a supportable format. Not really, because the frontend can often change his own internal resolution and pixel format (ex.: vnc).