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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Regards,

Anthony Liguori

> -- Jamie
>
>
>