From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BjcQW-0002Ea-Ix for qemu-devel@nongnu.org; Sun, 11 Jul 2004 07:23:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BjcQU-0002ED-O2 for qemu-devel@nongnu.org; Sun, 11 Jul 2004 07:23:24 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BjcQU-0002EA-KZ for qemu-devel@nongnu.org; Sun, 11 Jul 2004 07:23:22 -0400 Received: from [62.253.162.44] (helo=mta04-svc.ntlworld.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BjcNr-00058X-R1 for qemu-devel@nongnu.org; Sun, 11 Jul 2004 07:20:40 -0400 From: Julian Seward Subject: Re: [Qemu-devel] Reducing X communication bandwidth Date: Sun, 11 Jul 2004 12:22:02 +0100 References: <200407100945.06998.jseward@acm.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407111222.02531.jseward@acm.org> Reply-To: jseward@acm.org, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Johannes Schindelin Cc: qemu-devel@nongnu.org On Sunday 11 July 2004 10:53, Johannes Schindelin wrote: > Hi, > > On Sat, 10 Jul 2004, Julian Seward wrote: > > The attached patch against sdl.c fixes this. It keeps a shadow > > copy of video memory. When a request arrives at sdl_update() > > to redraw an area, the area is compared against the shadow copy, > > and only the parts that have really changed are passed to > > SDL_UpdateRect(). The comparison is done at a granularity of > > 32x32 chunks of pixels. > > Why does this remind me of VNC? In fact, that kind of application is the > exact reason I started my VNC patch. It could also be useful as a Windows > 98 Terminal Server... Exactly -- I got the idea from VNC. First I noticed that using qemu just as a remote X client gave appalling performance *but* when you run it on a remote VNC server and connect with vncviewer, the results is quite usable. That immediately suggests that vnc found a lot of redundant screen updates and did not bother to send them over the network, and at that point I started hacking :-) J