|
| From: | Anthony Liguori |
| Subject: | Re: [Qemu-devel] X support for QXL and SPICE |
| Date: | Fri, 11 Dec 2009 21:31:34 -0600 |
| User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
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
Does anything use Xrender for drawing glyphs these days?Certainly, with a compositing window manager, nothing is getting rendered by X...
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
- Solid fills and CopyArea requests are turned into SPICE
commands.
- The cursor is drawn using cursor commands
- 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.
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.
Scrolling is accelerated in VNC. In the Cirrus adapter, both X and Windows use a video-to-video bitblt, we use this to create a VNC CopyRect which makes scrolling and Window movement smooth.
However, as things stand right now, there is not much point in adding
this support, because X applications essentially always work like
this:
- render to offscreen pixmap
- copy pixmap to screen
There is not yet support for offscreen pixmaps in SPICE, so at the
moment, solid fill and CopyArea are the two main things that actually
make a difference.
Okay, that's in line with what my expectations were. So what's the future of Spice for X? Anything clever or is Windows the only target right now?
Regards, Anthony Liguori
| [Prev in Thread] | Current Thread | [Next in Thread] |