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 21:21:35 +0200

On Fri, 11 Dec 2009 13:04:02 -0600
Anthony Liguori <address@hidden> wrote:

> Hi Izik,
> 
> Thanks for the explanation.
> 
> Izik Eidus wrote:
> >> So from a protocol perspective, what are the advantages of Spice
> >> over VNC?
> >>     
> >
> >
> > Spice desgien is highly diffrence than VNC
> > The first thing about spice is that it isnt just a framebuffer
> > drawing and not a bitmaps protocol.
> >
> > Spice protocl support multiple graphics commands,
> 
> VNC actually does have high level 2d commands like CopyRect.  The
> higher end encodings (like Tight and ZRLE) provide for mechanisms to
> do operations like fill even with different types of patterns.
> 
> Do you have any performance data that demonstrates where SPICE does
> well compared to something like VNC?

I should speek with the marketing guys, will be able to answer on that
specific question in few days.


But simple 2D Commands are just not enougth for spice.
We have multiple drawing surfaces, that are depended on each other.
We Dont renender untill the very moment that the guest try to read its
video memory, we have video streaming, and we have cache based by the
guest driver.
We have private channels for stuff like keyboard, display and so on...


> 
> >  multiple surfaces
> > drawings,
> 
> VNC does not have a notion of off-screen pixmaps but it would be
> pretty easy to add.  I think the simpliest approach would be to
> introduce the notion of a Viewport which clips the visible screen to
> a smaller size. That way, you could resize the screen to 2x or 3x the
> viewable screen.  You could us things like CopyRect to blt from an
> off-screen surface to the on-screen surface.  I think the real
> question though is how much of a win is off-screen drawing?
> 
> We've always been very limited by the VGA devices we emulate so we've 
> never really tried to make the most out of VNC.
> 
> >  Spice is desgined to render as less as it can on the server
> > and instead to render on the client side much of the work,
> > To achive this spice use all kind of techniques such as depth
> > viewing tree.
> >   
> 
> I'm not familiar with what a "depth viewing tree".  Can you elaborate?

In it simplest way of working, we will take the simplest case of what
it is doing:
If you have application that rendered a window, and then it renendered
another window on top of it, you dont want to send the commands that
rendered the old window, beacuse the new commands hide the older one...

When the guest will try to read the video memory, you wont want the
server to render the old commands.

But you will want to rendner the old commands in case the new commands
are depended on the older commands...

> 
> > The patchs that we wanted to push into qemu were what is called VDI
> > interfaces, it allow to qemu work with what ever interface it want,
> > what so bad about that?
> >   
> 
> Those patches never made it to the list.


It will take some time, it is in our todo, we never expected qemu to
merge spice without this patches!


> 
> > I think we should allow freedom of choice to the users to decide
> > what protcol they want to use, Spice and VNC are all diffrent and
> > were born to meet diffrent goals.
> >   
> 
> What would be ideal, is if there was a mechanism whereas a client
> could connect to the VNC server, and get VNC traffic if it's a normal
> VNC client, but if it was a smarter client, got a more sophisticated 
> stream.  If that was something that was Spice or Spice-like, that
> would be perfect.
> 
> But to introduce another protocol where a user has to make a choice
> to use Spice over VNC, I think we need a really good justification
> for that.  It's really about complexity.  A user shouldn't have to
> know about Spice or VNC.  They shouldn't have to contemplate the
> trade-offs of whether their management tool is aware or not.  It
> should Just Work.


This why we suggest the VDI interface, to solve all this choicses we
made for the users,

Think about qemu give infastracture to multiple librarys to use it?
For example one user can use qemu with  VNC, one with SPICE, and one
can use qemu with diffrent private local rendering soultion (for highly
fast local 3d rendering...)


> 
> > I would happy to answer more questions if anyone have
> >   
> 
> Thanks.
> 
> Regards,
> 
> Anthony Liguori





reply via email to

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