[Spice-devel] Unfair comparisons with RDP

[Alon Levy]

On Sat, Jul 02, 2011 at 05:45:34AM -0400, John A. Sullivan III wrote:
> On Sat, 2011-07-02 at 04:56 +0200, Alon Levy wrote:
> > On Fri, Jul 01, 2011 at 09:40:41PM -0400, John A. Sullivan III wrote:
> > > On Fri, 2011-07-01 at 17:05 +0200, Alon Levy wrote:
> > > > On Fri, Jul 01, 2011 at 03:00:32PM +0200, Gianluca Cecchi wrote:
> > > > > On Fri, Jul 1, 2011 at 1:04 PM, John A. Sullivan III  wrote:
> > > > > > Interesting observation. That is true; we did not create separate VM
> > > > > > definitions for SPICE and TSPlus thus the TSPlus environment is using
> > > > > > the QXL driver.  Would we expect that to have any "supercharging" effect
> > > > > > on RDP?
> > > > > >
> > > > > >
> > > > > 
> > > > > Probably not, because afaik (that is not so much ;-) Remote Desktop
> > > > > (and probably tsplus too) works at the GDI call level, so it should
> > > > > not depend so much on video adapter/video driver...
> > > > > It was simply a question that arose analysing how to correctly
> > > > > replicate comparisons...
> > > > > Coming back to the test case and these operations:
> > > > > 
> > > > > rdp
> > > > > 17:             display desktop, i.e., minimize all open applications
> > > > > 42:             Paint existing LibreOffice document, i.e., restore from minimize
> > > > > 
> > > > > spice
> > > > > 61:             display desktop, i.e., minimize all open applications
> > > > > 92:             Paint existing LibreOffice document, i.e., restore from minimize
> > > > > 
> > > > > I think they are GDI ones, so that naturally when using rdp they are
> > > > > executed locally on client desktop (only the gdi directives are sent),
> > > > > while in spice (raster?) they will be network intensive (from a slow
> > > > spice implements a driver, which implements a large part of the gdi api. So any
> > > > operation that it doesn't implement is done via the windows gdi software rendering
> > > > and the result given to the driver (which is spice) as an image.
> > > > 
> > > > So in cases where the specific operations are all implemented by the driver the
> > > > performance should be identical. In other cases spice will be suboptimal, since
> > > > it will send the image and not the operation. In both cases the rendering should
> > > > be correct.
> > > > 
> > > > > link point of view).
> > > > > So probably an optimized rdp could never be beaten on too slow links?
> > > > > 
> > > > ><snip>
> > > Hmm . . . I remember you saying that the Windows product was actually
> > > more developed than the Linux product.  Could it be that you have
> > True
> > 
> > > implemented more of the GDI API than the X API (or whatever one uses for
> > > Linux) and thus my Linux client is more regularly falling back to
> > > sending images rather than directives?
> > Client != Guest. A confusion that arises all the time here :) The client
> > is *using* the graphics api on whatever platform. The linux client uses
> > pixman mostly. The windows client uses gdi. The gdi canvas (as the graphics
> > backend for the clients is called) has seen more usage / optimization I think,
> > so you are not wrong in your conclusion. There are actually two different clients
> > right now, spicec and any client based on the spice-gtk, such as vinagre or spicy.
> > Could you try any of the later to see if you get 100% cpu with them as well?
> <snip>
> Sorry - I realize I stated that backwards! However the 100% CPU problem
> is a different one.  We are noticing that the Windows server viewed via
> the Debian client is laggard but CPU utilization is fine on both client
> and server.  The problem with 100% CPU utilization is when we have a
> Fedora 15 server.
by server you mean guest? So this is the driver taking 100% cpu?

> 
> I assume spicy is not the --enable-gui option in spice-0.8.1.  I've
> downloaded http://www.spice-space.org/download/gtk/spice-gtk-0.6.tar.bz2
> but I assume that is an older client.  I'm having a bear of a time
> compiling it on Debian including having to add #include <stdint.h>
> to /usr/local/include/spice-1/spice/controller_prot.h so something
> seemed wrong.
> 
> Argh! My installation of Wireshark must have pulled in some GTK+3
> libraries. All GTK apps seem broken.  It doesn't matter whether I
> compile --with-gtk=2.0 or 3.0, I keep getting "GTK+ 2.x symbols
> detected. Using GTK+ 2.x and GTK+ 3 in the same process is not
> supported."  I suppose I'll need to strip this down and perhaps install
> Fedora.  Won't be able to get to that until Monday earliest.
>