[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

From: Anthony Liguori
Subject: Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
Date: Thu, 31 Jan 2008 16:40:08 -0600
User-agent: Thunderbird (X11/20071229)

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

But your guest isn't displaying to the entire screen... I was assuming a 32-pixel height, 1024 pixel wide region.


Anthony Liguori

-- Jamie

reply via email to

[Prev in Thread] Current Thread [Next in Thread]