[Spice-devel] Unfair comparisons with RDP

[Alon Levy]

On Fri, Jul 01, 2011 at 09:18:14AM -0400, John A. Sullivan III wrote:
> On Fri, 2011-07-01 at 15:00 +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
> > link point of view).
> > So probably an optimized rdp could never be beaten on too slow links?
> > 
> > So my question is: could it be that instead of say spice vs tsplus in
> > general, we ought to go in determining what is the minimum necessary
> > bandwith to give the final user an acceptable experience (need to
> > define "acceptable" ;-) ?
> > 
> > Or, if I'm not wrong, as pcoip incorporates in some way both rdp and
> > raster capabilities so that it is able to "automatically" determine
> > what to use, the right way should be to do something similar for
> > spice?
> > 
> > Gianluca
> That's an interesting question.  I don't want to tie up the devs too
> badly on things I can research myself and I've not yet fully read all
> the protocol documents (not that I'd fully understand them either!) but
> this is an area where I am confused.
> 
> From reading the overview documents, I was under the impression that
> SPICE worked so well because it was not transferring the screen as an
> image but rather making native calls to the client's graphics engine,
That's correct.

> thus, in my ignorance, I suppose we would be sending GDI commands to a
> Windows client and X(?) to a Linux client (as you can tell, I know far
> less about graphics rendering that I should).  However, I see all these
> configuration options for compressing images so I really don't know if
> SPICE is transferring images or making low level graphic calls to the
> client's underlying graphics subsystem.
The fact is those things are not contradictory. When you implement the GDI
layer from the driver side part of it is dealing with bitmaps. This ends
up as spice protocol messages going to the client, and since we have a bitmap
we get to choose what to do with it, such as what compression to use.

Another point is the video recognition and recompression layer, which is not
part of the driver at all but part of the server, taking repeated bitmap draws
to the same area and converting it to a mjpeg stream. This also gets some options.

> 
> Perhaps SPICE is capable of both.  The overview documents do talk about
> rendering on the client when possible but if the client is weak (for
> lack of a better term), the rendering can happen on the server.  I
> wonder how I can tell where my rendering is occurring?
> 
> From previous comments on the list, I am under the impression that SPICE
> should outperform RDP so I'd be a little surprised to see SPICE sending
> bulky images and RDP sending GDI directives but I really don't know.
> Thanks - John
>