From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEh9y-0001ow-UT for qemu-devel@nongnu.org; Thu, 20 Sep 2012 09:51:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEh9p-0003BH-4R for qemu-devel@nongnu.org; Thu, 20 Sep 2012 09:51:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEh9o-0003Ax-TB for qemu-devel@nongnu.org; Thu, 20 Sep 2012 09:51:09 -0400 Message-ID: <505B1F46.1080303@redhat.com> Date: Thu, 20 Sep 2012 15:51:02 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1348053341-29212-1-git-send-email-kraxel@redhat.com> <1348053341-29212-8-git-send-email-kraxel@redhat.com> <505AB4C9.9070809@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 7/9] fbdev: move to pixman List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: "qemu-devel@nongnu.org" Hi, > It might be a good idea to get rid > of DisplayAllocator altogether. After some digging in the source code: Yes, I think so. Look, we have *two* concepts for avoiding memcpy: The first is the DisplayAllocator. Only implemented by SDL, which is scheduled to be downgraded by anthonys gtk patches. Doesn't really fit into the concept of displaychangelisteners coming and going at runtime, and also not of having multiple displaychangelisteners (like sdl+vnc at the same time). It allows vga emulation to render directly into a SDL buffer. The second is qemu_create_displaysurface_from(). It allows vga emulation hand out a surface with direct pointer to the guests video memory for displaychangelisteners to read from. You can't have both (i.e. the guest will never ever write directly into the SDL buffer), there will always be at least one memcpy. So what happens in practice? In any graphics mode relevant today vga emulation will use qemu_create_displaysurface_from(). Whenever a DisplayAllocator is present or not doesn't make any difference then. In case vga emulation has to render something because the guests video memory can't be represented directly as displaysurface (text mode, gfx modes with <= 256 colors) it will allocate a surface where it will render the screen to and will use the SDL DisplayAllocator if registered. I somehow doubt text mode acceleration is worth the complexity+confusion DisplayAllocator adds to the picture. Also I'd like to have reference counting for display surfaces because I can offload the display scaling to a separate thread then. Guess this is easier to implement when zapping DisplayAllocator first. cheers, Gerd