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

[Izik Eidus <ieidus@redhat.com>]

On Fri, 11 Dec 2009 23:08:01 +0100
Alexander Graf <agraf@suse.de> wrote:

> 
> On 11.12.2009, at 22:13, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 14:46:55 -0600
> > Anthony Liguori <anthony@codemonkey.ws> 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).
> 
> The ring is from qemu <-> guest, right? I mean, qemu <-> client would
> be a TCP transport anyways, so the ring argument is void.


Beside the fact that we dont have the network overhead...

> 
> > 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....
> 
> I definitely understand your point of having a single protocol. The
> good news is that your physical machine stuff isn't released yet
> (AFAIK), so luckily there's still time to change parts of the
> protocol :-).
> 
> > 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...
> 
> These should be fairly easy to implement in VNC too. In fact, I
> remember a project implementing off-screen drawing in VNC using a
> larger region of the screen than what was visible and then copyrect
> them in.

In theory you can even change the whole of VNC into SPICE or the whole
of VI into EMACS, so???, I personaly think changing code isnt the
problem, the problem is always the desgien, and SPICE have fandumental
diffrent desgien than VNC, (Here you can say: OK I can make my VNC
desgien like SPICE, or you can say I think SPICE dsgien is bad, or you
can just use SPICE...)

> 
> > 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, in fact VNC would wait for the refresh timer of the VGA
> framebuffer dirty thing and only send a single update too.

Yes but what will happen if you run vnc using paravirtual device?

> 
> But Anthony's point was that rectangle drawing isn't used anymore.
> Instead gtk/qt just draw it themselves and tell the X driver "here's
> an image".


And what about 3D ? or Xrender operations such as composing ?
(streching)?



> 
> Alex