[Qemu-devel] Reducing X communication bandwidth

[Julian Seward]

QEMU is great, but one specific problem has made it unusable
for me so far.  The (fast) machine I want to run QEMU on is not
the same as my (slow) machine which is on my desk. That is, 
I want to do the usual X "export DISPLAY=someothermachine:0.0"
game.

These machines are connected by an old-fashioned 10 Mbit/sec
network, which you may argue is obsolete, but I would argue 
represents reasonably the approximate bandwidth of 802.11b/g
LANs which are common now.

Anyway, QEMU from cvs is unusable like this, at least when
running WinXP or Win2K.  The SDL layer (qemu/sdl.c) blasts
huge numbers of pixels across the network in response to even
the simplest graphical operations.  Notably, moving the mouse
pointer is appalling, with an update rate of about twice per
second, which is hopeless.

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.

Currently I have an XP session running for several hours.  
Without the patch, 2.7 million of these 32x32 chunks would
have been transmitted across the network, whereas with it,
the number is reduced to 322000, a factor of 9 reduction.
This makes QEMU actually usable for me.  The most dramatic
improvement is merely moving the mouse pointer, where 
typically QEMU requests 32 such chunks to be drawn, but only
1 or 2 are actually necessary, massively improving mouse-pointer
responsiveness.  Of course it brings no benefit if sdl_update
is constantly asked to draw a series of "new" images, but 
that generally doesn't appear to be the case.

Given that currently QEMU is (imo) unusable unless X client
and server run on the same machine, I think this is a good
candidate for cvs.  It may need to handle the case where 

   screen->format->BytesPerPixel != 4

I don't know if that situation happens or not, but the 
patch is a good start.

J

remote_x_client.patch
Description: Text Data