From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kchmf-000412-JR for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:32:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kchmc-0003wF-KQ for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:32:04 -0400 Received: from [199.232.76.173] (port=38832 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kchmc-0003vm-7f for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:32:02 -0400 Received: from an-out-0708.google.com ([209.85.132.249]:57917) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kchmc-0003rL-7h for qemu-devel@nongnu.org; Mon, 08 Sep 2008 10:32:02 -0400 Received: by an-out-0708.google.com with SMTP id d18so253738and.130 for ; Mon, 08 Sep 2008 07:32:01 -0700 (PDT) Message-ID: <48C5372F.9080903@codemonkey.ws> Date: Mon, 08 Sep 2008 09:31:11 -0500 From: Anthony Liguori 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> <48C5349D.60707@eu.citrix.com> In-Reply-To: <48C5349D.60707@eu.citrix.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: Stefano Stabellini Cc: qemu-devel@nongnu.org Stefano Stabellini wrote: > 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. > It requires two paths in the code to handle the case where the backend can't handle conversion itself. If we're not getting any sort of benefit from offloading, then I don't see the need for increased code complexity. >> 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). > Not when using SDL on X11. It will use an XShmImage if possible, otherwise falling back to a normal XImage. There's really no other way to do surfaces in X11 without using one of the extensions (like DGA). Regards, Anthony Liguori