Re: [Qemu-devel] [PATCH 0 of 3] vnc and vga improvements

[Gerd Hoffmann <kraxel@redhat.com>]

Anthony Liguori wrote:
> Stefano Stabellini wrote:
>> Hi all,
>> This is a three patch series coming from xen-unstable to improve vnc
>> and vga performances.
>>
>> The first patch implements dynamic colour depth changes in vnc.c:
>> this way the vnc server can change its own internal colour depth at run
>> time to follow any guest resolution change.
>>
>> The second patch implements the WMVi vnc extension in the qemu vnc
>> server, so that we can also notify a vnc client when we change
>> internal colour depth and offload any possible colour conversion to the
>> client.
>>
>> The third patch implements sharing of the display pixel buffer between
>> vnc.c and vga.c, in order to save a lot of memcpy's.
>>
>> The idea is that vnc.c (and in the near future sdl.c too) strictly
>> follows the guest display resolution and notifies the client of any
>> change. As a consequence we can save two colour conversions: one between
>> vga and vnc, another one between the vnc server and the vnc client.
>>   
> 
> I have mixed feelings about this.  On the one hand, reducing the copying
> is a good thing.  On the other hand, we pretty much make it impossible
> to ever support multiple clients.

Getting rid of the color space conversions is a good thing, even in case
we can't drop the separate buffers and the memcpys.  Right now the vnc
server runs at 32bit unconditionally.  Having it run at 16bpp in case
the guest uses 16bpp is still a win because we (a) have to handle less
memory and (b) can to a straight copy instead of a pixel conversion.

And maybe the buffer sharing can be implemented in a way that we can
turn it on and off at runtime?  So the common case of at most one client
can run with buffer sharing, otherwise we copy to per-client buffers?
I'm not a vnc protocol expert though.

Looking at the patches, it seems buffer sharing is optional already
(usage depending on the color depth right now it seems).

cheers,
  Gerd