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 :-) -- Jamie
