On 12.12.2009, at 00:58, Soeren Sandmann wrote: > Hi, > > Here is an overview of what the current QXL driver does and does not > do. The parts of X rendering that are currently being used by cairo > and Qt are: > > - Most of XRender > - Image compositing > - Glyphs > - Trapezoids > > - Bits of the core protocol: > - Solid fills > - CopyArea > > The X driver for the QXL device is not yet very sophisticated. What it > does is basically this: > > - It keeps a separate memory framebuffer uptodate using > software
Very good :-). > - Solid fills and CopyArea requests are turned into SPICE > commands. The Tight VNC extension implements commands for this. We only implement CopyArea in Qemu though. > - The cursor is drawn using cursor commands VNC (the protocol) implements this. > - For other things, bitmaps are sent across the wire > - It uses the hashing feature of SPICE to only send > hashcodes for those bitmaps if it can get away with > it. I think VNC doesn't have a notion of this yet. It should be fairly easy to add though. > Even this simple support provides a better user experience than VNC > because scrolling is accelerated and doesn't result in a huge bitmap > getting sent across the wire. (I don't know if VNC has support for > bltblt, but even if it does, a screenscraping VNC server can't easily > make use of it). What really surprises me is that this is pretty much what Xvnc does. Except for the bitmap cache of course. Do you get better performance with SPICE on Linux guests than you get with direct Xvnc forwarding and -encodings 'tight copyrect'? What does performance look like in comparison to Xrdp? That one does implement bitmap caches. It should be really really close, right? Don't get me wrong - I'm not trying to talk anyone into what's best for anyone. I'm trying to understand what speed we can expect from which solution and what actually speeds up what :-). Alex