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

[Paul Brook]

> 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.

Paul