From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JKiZ1-0002eX-4n for qemu-devel@nongnu.org; Thu, 31 Jan 2008 18:11:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JKiYy-0002aF-LH for qemu-devel@nongnu.org; Thu, 31 Jan 2008 18:11:22 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JKiYy-0002a4-Ez for qemu-devel@nongnu.org; Thu, 31 Jan 2008 18:11:20 -0500 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JKiYy-0000Qm-94 for qemu-devel@nongnu.org; Thu, 31 Jan 2008 18:11:20 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JKiBK-0008HN-JN for qemu-devel@nongnu.org; Thu, 31 Jan 2008 17:46:55 -0500 Received: by rv-out-0910.google.com with SMTP id g11so1885297rvb.22 for ; Thu, 31 Jan 2008 14:46:38 -0800 (PST) Message-ID: <47A24E48.30402@codemonkey.ws> Date: Thu, 31 Jan 2008 16:40:08 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support References: <13FD6BC9-36B9-4911-82D4-739AC5E10E66@kberg.ch> <4E3770A5-4564-49DF-B868-511F5935F7CD@csgraf.de> <40275543-3906-421D-B6DB-13B1BA72E35B@kberg.ch> <47A0F22A.9040704@codemonkey.ws> <20080131094613.GE4003@shareable.org> In-Reply-To: <20080131094613.GE4003@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; 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: qemu-devel@nongnu.org Jamie Lokier wrote: > Anthony Liguori wrote: > >> VGA framebuffer operations come in as memory operations. They're >> tracked by watching what memory gets dirtied. This can only operate at >> a page-granularity so this results in scan-line granularity updates. >> The VNC front-end goes to great lengths to keep a shadowed framebuffer >> and reduce these updates to a smaller update region. You could possibly >> look at refactoring that code. However... >> > > That update region code should probably be moved to something generic > and made into a generic display option. > > Reducing update region is logically orthogonal, and could work with > any update method (e.g. local X11, remote X11, local X11-OpenGL, > remote X11-OpenGL, SDL etc.). With some of those, for some people > (especially some but not all remote setups) it might be worth it. > > >> I would be amazed if screen updates on OS X are so slow that it would >> make a difference if updates are in scanline granularities. The copying >> latency is nothing compared to the other latencies in QEMU. A modern >> processor can move memory at an extremely high speed. >> >> At a refresh rate of 30 times per second, this is only ~4MB of data for >> mouse movements. A typical processor can easily handle many GB of data >> per second. >> > > That's 16MB/frame on an Apple Cinema display at 32bpp, which is > 0.5GB/sec. Not too much, but not free either :-) > But your guest isn't displaying to the entire screen... I was assuming a 32-pixel height, 1024 pixel wide region. Regards, Anthony Liguori > -- Jamie > > >