From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJFNN-0007Nm-Fx for qemu-devel@nongnu.org; Fri, 11 Dec 2009 18:58:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJFNI-0007IG-Re for qemu-devel@nongnu.org; Fri, 11 Dec 2009 18:58:20 -0500 Received: from [199.232.76.173] (port=47766 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJFNI-0007I5-DV for qemu-devel@nongnu.org; Fri, 11 Dec 2009 18:58:16 -0500 Received: from nfitmail.nfit.au.dk ([130.225.31.129]:8008 helo=smtp.nfit.au.dk) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJFNH-0005B3-Bf for qemu-devel@nongnu.org; Fri, 11 Dec 2009 18:58:15 -0500 Sender: sandmann@camel26.daimi.au.dk References: <1393046876.1549021260539141025.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <4B226BFC.1040606@codemonkey.ws> <20091211204828.464707cf@redhat.com> <4B2297A2.8040102@codemonkey.ws> <20091211212135.645864f9@redhat.com> <4B229DCE.7070500@codemonkey.ws> <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211222101.5e924d20@redhat.com> <4B22AFBF.6080709@codemonkey.ws> <20091211231334.3d8a599f@redhat.com> <8BF07900-1F21-4E1C-AFC7-FF9CC47525A3@suse.de> <20091212004635.0b57a8c0@redhat.com> From: Soeren Sandmann Date: 12 Dec 2009 00:58:13 +0100 In-Reply-To: <20091212004635.0b57a8c0@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] X support for QXL and SPICE List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Izik Eidus Cc: Yaniv Kamay , Alexander Graf , qemu-devel@nongnu.org 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 - 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. (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). I believe some parts of XRender can be supported within the existing SPICE protocol, and that it would be fairly straightforward to add the other parts. 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. Soren