qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Spice project is now open


From: Izik Eidus
Subject: Re: [Qemu-devel] Spice project is now open
Date: Fri, 11 Dec 2009 23:13:34 +0200

On Fri, 11 Dec 2009 14:46:55 -0600
Anthony Liguori <address@hidden> wrote:

> Izik Eidus wrote:
> > I personaly dont like mjpeg, and yes in the end of the day you can
> > add the video streaming into vnc, but what is the point here?
> >   
> 
> What I'm trying to understand is, what can we do with Spice that we 
> couldn't possibly do with vnc.  That means understanding each feature 
> and then figuring out if there's a vnc analog.
> 
> If there are compellingly unique features to Spice that can't be 
> duplicated in vnc, then it's a no brainer.  If you can do most things
> in vnc but it would be hackish whereas Spice makes it all elegant,
> then provided we can merge Spice without a huge amount of pain, then
> it's a net win.
> 
> However, if we need to make a few changes to vnc in order to get the 
> same performance as Spice, then it's not quite as clear that it's
> what we should be using.
> 
> We're talking about a major change here.  There is a ton of
> management software that assumes vnc today.  Even though there are
> Spice clients out there, there are embedded vnc clients in certain
> tools today along with java applets.
> 
> That's not to say we shouldn't embrace Spice, we just have to make
> sure we have a good reason to.

Ok, I understand your concerns.

But even though that spice and vnc achive in the end of the day the
same thing - they both allow remote rendering, they have fendumental
diffrent architacture.

Spice server work with a ring to the guest, it was build from day one
to work like that, In addition it was built from day one so that the
server will render only what it must to render (to allow much higher
virtualization denticity).

Just to make clear how much spice is diffrence from VNC is by the fact
that only the library itself (not including the drivers) have 128,277
lines of code inside it. (In my old qemu repo i see almost 600,000
lines for qemu) so this should give better prespective on how much
spice is diffrent from vnc.

So ofcurse in theory you can take all this 128,000 lines and push them
into qemu-vnc.c ?, but you got to remember that spice is not just
specific qemu thing, Spice should be used to work on physical machines
too, just cutting all this lines of code from spice and throw it into
qemu-vnc.c will be meaning a fork of spice inside qemu....

It isnt just the rings and the rendering style that make spice
diffrence, it is the channels it have for each compoment, it is the
multiple drawing surfaces, and so on...

This why the VDI interfaces were made, it was made so who ever used
VNC, can still use it, whoever want to use SPICE can still use spice,

By merging SPICE you just merge VDI interfaces, not the library
itself, it is so self contained thanks to the VDI interfaces, that it
almost dont touch anything inside qemu, I belive this was one of the
best aurgoments when Avi pushed kvm into the kernel - the fact that it
was a module that can be easyly removed if ppl dont want to use it. 


> 
> > We acctuly want to kick away that video streaming, and move into the
> > DirectX and X video extentions video support (that will be made
> > using the qxl driver) - will give much better performence.
> >   
> 
> Okay, I suspect we're in agreement here then.

Thanks God ! ;-)


> 
> >> By the time we get to video memory, the display server has already 
> >> straightened out what portions of the screen are visible and what 
> >> aren't.  It will not render a hidden window and then render
> >> another window on top of it.
> >>     
> >
> > I dont understand, if you have applciation that draw Rectangle, and
> > just another Rectanlge on top of it, wont it hide it?, doesnt we
> > want just to send the newest Rectangle?
> >   
> 
> If you're using something like gdk, the toolkit double buffers
> windows by default and does a single flip on expose.  So this sort of
> thing never makes it way to the X server.  But the other point is, if
> you draw a rectangle with gdk, all the X server ever sees is the
> drawing of an image.

Spice work on the driver primitives it doesnt know what is GDK, if the
X driver will draw rectangle and then another rectangle, VNC will have
to draw it twice, spice not.


> 
> > Well any driver can use what ever spice commands it want, the X
> > driver doesnt have to use all the spice commands, what is so bad
> > about that? 
> 
> What I'm asking is what's the performance of the X driver vs. say,
> VNC? Do these high level operations really make sense for a Linux
> guest if we cannot ever implement them in an X driver?

Ohh, The performence is much better user interactive and higher density
the user interactive come from the paravirtual device and the fact that
we dont send commands that were "hide" into the client.

The higher density come from the fact that the server that run the VM
(qemu) almost never have to render the stuff....


> 
> I can see where this is a win with Windows because you can hook into 
> GDI, but I'm not sure that this could ever do better than say, NX 
> without something really clever or really deep integration with
> toolkits.
> 
> > Spice is not protocol for just windows or X or whatever, it id
> > display protocol that implment common display commands that can be
> > used over every display system.
> >   
> 
> Are there plans to integrate Spice support in gdk (or cairo)?  I
> think that would be required to get performance parity with Windows.

Can you expline more what you mean?
Spice work on the driver primitives, so I am not sure I understand here
what you suggest...

Thanks.

> 
> Regards,
> 
> Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]