Anthony Liguori wrote:
VGA framebuffer operations come in as memory operations. They're
tracked by watching what memory gets dirtied. This can only operate at
a page-granularity so this results in scan-line granularity updates.
The VNC front-end goes to great lengths to keep a shadowed framebuffer
and reduce these updates to a smaller update region. You could possibly
look at refactoring that code. However...
That update region code should probably be moved to something generic
and made into a generic display option.
Reducing update region is logically orthogonal, and could work with
any update method (e.g. local X11, remote X11, local X11-OpenGL,
remote X11-OpenGL, SDL etc.). With some of those, for some people
(especially some but not all remote setups) it might be worth it.
I would be amazed if screen updates on OS X are so slow that it would
make a difference if updates are in scanline granularities. The copying
latency is nothing compared to the other latencies in QEMU. A modern
processor can move memory at an extremely high speed.
At a refresh rate of 30 times per second, this is only ~4MB of data for
mouse movements. A typical processor can easily handle many GB of data
per second.
That's 16MB/frame on an Apple Cinema display at 32bpp, which is
0.5GB/sec. Not too much, but not free either :-)