Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Wed, Jan 21, 2009 at 01:50:15AM +0000, Paul Brook wrote:
> > Steps to reproduce:
> > - Start qemu (doesn't matter which target or guest OS).
> > - Press c-a-2 to switch to the monitor.
> > - type "help<enter>"
> > - 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.

I just tried running with '-serial /dev/null -parallel /dev/null' and
the slow down problem disappeared.  I am suspicious of this part of the
6336 commit:

@@ -1360,12 +1352,137 @@ void qemu_console_copy(QEMUConsole *console, int 
src_x, int src_y,
                 int dst_x, int dst_y, int w, int h)
 {
     if (active_console == console) {
-        if (console->ds->dpy_copy)
-            console->ds->dpy_copy(console->ds,
-                            src_x, src_y, dst_x, dst_y, w, h);
-        else {
-            /* TODO */
-            console->ds->dpy_update(console->ds, dst_x, dst_y, w, h);
-        }
+            dpy_copy(console->ds, src_x, src_y, dst_x, dst_y, w, h);
     }
 }

To me this looks like what used to do a copy if the console was active,
and an update if it was not, has turned into a copy at all times.  This
sounds like potentially doing expensive work on inactive consoles.  This
is what made me think of trying to disable the parallel and serial
consoles.

I made this little patch for console.c:

--- qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60/console.c       
2009-01-21 09:26:06.000000000 -0500
+++ qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60.new/console.c   
2009-01-21 10:12:29.000000000 -0500
@@ -1433,7 +1433,11 @@
                        int dst_x, int dst_y, int w, int h)
 {
     if (is_graphic_console()) {
-        dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h);
+        if(active_console->ds == ds) {
+            dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h);
+        } else {
+            dpy_update(ds, dst_x, dst_y, w, h);
+        }
     }
 }

And then it is back to proper speed for me across ssh.  Does it make sense?

-- 
Len Sorensen