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. > > 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 > _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
