From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPSEe-000725-Ne for qemu-devel@nongnu.org; Tue, 20 Jan 2009 20:50:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPSEa-0006xR-2S for qemu-devel@nongnu.org; Tue, 20 Jan 2009 20:50:28 -0500 Received: from [199.232.76.173] (port=36589 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPSEZ-0006x3-OP for qemu-devel@nongnu.org; Tue, 20 Jan 2009 20:50:23 -0500 Received: from mx20.gnu.org ([199.232.41.8]:58038) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LPSEZ-0002x8-Eh for qemu-devel@nongnu.org; Tue, 20 Jan 2009 20:50:23 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPSEX-0001Sy-CZ for qemu-devel@nongnu.org; Tue, 20 Jan 2009 20:50:21 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Re: Extremely slow graphic updates Date: Wed, 21 Jan 2009 01:50:15 +0000 References: <20090119162633.GO29175@csclub.uwaterloo.ca> <4975B3F6.6050706@eu.citrix.com> <200901201811.19920.paul@codesourcery.com> In-Reply-To: <200901201811.19920.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901210150.17344.paul@codesourcery.com> 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 Cc: Lennart Sorensen , Stefano Stabellini > Steps to reproduce: > - Start qemu (doesn't matter which target or guest OS). > - Press c-a-2 to switch to the monitor. > - type "help" > - Watch the output slowly appear over the next 30 seconds > > Running qemu over a forwarded X connection from a different machine (i.e. > ssh -X) suffers a marked slowdown. With this configuration the early x86 > boot stages are visibly much slower, in addition to the virtual console > slowness mentioned above. I've applied a patch to fix this. The problem was that we were incorrectly using SDL_Flip in sdl_update. This is fundamentally wrong because the blit immediately above has only updated the recently changes section of the image. With a flipped surface the contents will be the frame before last (if not the one before that), so we'd actually need to blit everything that has changed in the last 2 (or 3) frames. However we don't set SDL_DOUBLEBUFFER when SDL_SetVideoMode, so SDL_Flip this is just a confusing way of writing SDL_UpdateRect(real_screen, 0, 0, 0, 0); On systems where copying to the front buffer is expensive (in particular remote connections, or primitive Xorg drivers), needlessly refreshing the whole display has a huge effect on the cases mentioned above. I've applied a patch to use the correct SDL_UpdateRect call instead. This gets us almost back where we started. The virtual consoles are still slow over a remote connection. The text terminal code generates a lot of small redundant update. It appears that these now require an X server round trip, where they didn't before. I'm not sure why, I can only guess that the blit rather than direct framebuffer access is foiling some internal SDL/X dirty region tracking. Paul