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

[Izik Eidus <ieidus@redhat.com>]

On Fri, 11 Dec 2009 15:54:52 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Izik Eidus wrote:
> >>>> 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.
> >   
> 
> The point is, there isn't a "draw a rectangle" primitive in X.  There 
> also isn't a "draw some text using this font" in X.[1]
> 
> These things exist at higher levels (like GTK and QT).
> 
> [1] there actually are but modern applications don't use them.


While X can use just the Fill and Copy commands for spice, no one block
driver writer to add the GTK / QT levels you are talking about and send
this commands into spice (Xrender???), In addition to the Fill and Copy
commands spice can help improve performence with offscreen surfaces
support that allowing sending the pixmaps in the background while the
network is idle.

We are currently at the moment just implmented the X driver and we are
working to add better support for spice in this area (probably
it will be improvments regerding to xrender), so this parts have still
big potential to improve in spice.

In addition when we will merge the 3d support, driver would be able to
translate opengl commands into spice 3d commands.



> 
> > 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....
> >   
> 
> With the Linux guest driver?  If you can quantify that, it would be
> very useful.

The X driver is still very new, we have still a way to go to add all
what X need to achive the performence spice can offer.

> 
> >> 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...
> >   
> 
> I think the point I'm trying to get across, is that Windows has a 
> centralized architecture of drawing primitives and interfaces that is 
> relatively easy for drivers to hook into.
> 
> Linux doesn't have this.  Different things are handled in different 
> places and some layers (like GDK) aren't really made for hooking into.
> 
> What I'm trying to understand is whether it will be possible to 
> implement a lot of the Spice accelerations for Linux guests.



Xrender, and Opengl would be possible to be implment in spice
I think Xrender is what Cairo use for hardware accelration and this
much of what you need no?

> 
> Regards,
> 
> Anthony Liguori