[Spice-devel] Unfair comparisons with RDP

[John A. Sullivan III]

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.
<snip>
Hmmm . . . as I think about it, this is why I was surprised that the
streaming video performance was not better and why MJPEG mattered at all
so I'm sure there's some kind of fundamental misunderstanding on my part
and perhaps the part of other SPICE newbies.

Let's go back to the classic scenario of a user watching a YouTube video
in their browser.  If they are watching it locally, the local computer
is decoding the stream and sending GDI or X (is X the proper term for
the graphics rendering engine in Linux?) commands to the local video
output.

If they are using SPICE to view the guest, I was assuming that the guest
is decoding the video stream and the SPICE server on the host is then
sending the GDI or X commands to the SPICE client.  Thus, unless those
commands consume a lot of bandwidth, why would the performance the
client sees be any slower than if they were playing it locally if it is
the same set of GDI or X commands?

Is the bottleneck not the SPICE communication between SPICE server and
client but rather the QXL communication between guest and host, i.e.,
the guest is decoding flv but then sending MJPEG to the host and that's
the bottleneck? Then again, that's a backplane connection and should be
oodles faster than any Internet connection.

Where is my understanding broken? Thanks - John