[Spice-devel] Unfair comparisons with RDP

[John A. Sullivan III]

On Sat, 2011-07-02 at 21:52 +0200, Alon Levy wrote:
> On Sat, Jul 02, 2011 at 02:34:15PM -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.
> > <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?
> 
> Bandwidth of Youtube video: (guessing) 200 KB/sec
> Bandwidth of resulting GDI writes (assume uncompressed frames of 320x240 32bps, 20 fps, again
> I know the numbers are wrong but for ball park figures): 6000 KB/s
> 
> Bandwidth of mjpeg stream: don't know. somewhere in the middle.
Thanks for taking the time to explain this; I hope it is benefiting
someone else besides just me! Let me see if I understand.  So this is a
case where sending the GDI writes is actually more bandwidth intensive
than sending some form of bitmap (not sure if that is the correct term)
so we stop sending GDI writes and instead transmit MJPEG frames which
are worse than FLV but better than GDI writes?

So my misunderstanding was the assumption that sending GDI directives is
always much lower bandwidth than sending an image of the portion of the
screen which has changed.  Am I close?

Thus our goal is to find some better form of image transmission for
those cases where it is more efficient to send an image than to send
GDI/X directives?

Hmmm . . . I wonder of that threshold is different between GDI and X?
Probably something Andrea will have to take into account in his project.
Thanks again - John
> 
> > 
> > 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.
> No, that isn't the problem. The problem is that the mjpeg stream uses much
> more bandwidth then the flv.
> 
> > 
> > Where is my understanding broken? Thanks - John
> >