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

[Izik Eidus]

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

> Izik Eidus wrote:
> > 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... 
> 
> The video streaming is an encoding heuristic though, right?
> 
> The lack of guest visible rendering is interesting.

The video streaming now is motiation jpeg due to patents problems.

What you mean lack of guest visible rendering?, I might didnt
understand you


> 
>   
> 
> >> 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... 
> 
> Ah, this is unique to a windowing protocol.  A framebuffer protocol
> does not have to worry about this because the OS does it for you.

Not true.
This is optimization for remote rendering, in physical machines we can
rendner what ever we want, it take more cpu to try to use trees in
order to render the right things....
But with remote machines, we dont want to stress the network, so we
want to transfer just what we really need.

> 
> How well does this work with a Linux guest?  To get a lot of this
> level of information, you have to hook in at the X protocol level
> (which is what NX does).  Can you really do much at the X driver
> level?

Well we have X driver, why would there be any problems with X?

Spice driver to X (I mean from the X prespective on things) is just
another display driver.


> 
> Of course, a lot of interesting stuff (like drawing ops and text 
> rendering) doesn't even happen in the X server these days.
> 
> >>> 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,
> >   
> 
> Okay, but it's hard to evaluate that suggestion without seeing the
> VDI interface :-)

No problems!
http://www.spice-space.org/docs/vd_interfaces.pdf

> 
> > 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...)
> >   
> 
> As I said, I don't have a problem with externalizing things.  I think 
> there's some discussion about how best to do that.  For instance, I 
> think we want to avoid shared library plugins as it introduces a good 
> deal of instability into our address space.

Well why libc is diffrent then?

> 
> Regards,
> 
> Anthony Liguori