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: Alexander Graf
Subject: Re: [Qemu-devel] Spice project is now open
Date: Fri, 11 Dec 2009 23:08:01 +0100

On 11.12.2009, at 22:13, Izik Eidus wrote:

> 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).

The ring is from qemu <-> guest, right? I mean, qemu <-> client would be a TCP 
transport anyways, so the ring argument is void.

> 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.

> 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.

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".

Alex



reply via email to

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