From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LP5pQ-0001a8-8E for qemu-devel@nongnu.org; Mon, 19 Jan 2009 20:54:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LP5pO-0001Zd-O5 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 20:54:55 -0500 Received: from [199.232.76.173] (port=52801 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LP5pO-0001Za-Gz for qemu-devel@nongnu.org; Mon, 19 Jan 2009 20:54:54 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:35258) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LP5pO-0007LQ-5M for qemu-devel@nongnu.org; Mon, 19 Jan 2009 20:54:54 -0500 Received: by qyk13 with SMTP id 13so4396604qyk.10 for ; Mon, 19 Jan 2009 17:54:52 -0800 (PST) Message-ID: <49752EE0.7060700@codemonkey.ws> Date: Mon, 19 Jan 2009 19:54:40 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20090119162633.GO29175@csclub.uwaterloo.ca> <20090119194221.GS29175@csclub.uwaterloo.ca> <20090120005351.GV29175@csclub.uwaterloo.ca> <200901200133.25029.paul@codesourcery.com> In-Reply-To: <200901200133.25029.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Extremely slow graphic updates Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Stefano Stabellini , qemu-devel@nongnu.org, Lennart Sorensen Paul Brook wrote: >> 'ssh -X fastserver' and running qemu there. With the new display code >> this has made qemu very slow and hardly useable. >> > > I'm seeing similar extreme slowness even on a local machine. > > Particularly noticeable is that the monitor displayed on a qemu virtual SDL > console (i.e. the defaut) slow enough to be practically unusable. It's taking > the best part of a second to rendering a character. > > This is on an otherwise fast machine that does not have accelerated X drivers, > which suggests we're doing something really dumb like reading from video ram. > > I have confirmed that this is caused by r6336. > I'll look into this tomorrow morning. Regards, Anthony Liguori > Paul >