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

[Izik Eidus]

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

> Izik Eidus wrote:
> > 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.
> >   
> 
> The approach taken by THINC was to support just a YUV overlay.  That 
> gets you half way there in terms of compressing a video stream.
> Since most hardware provides YUV->RGB acceleration, it fits very well
> into existing driver architectures.  For instance, VMware VGA
> supports YUV overlays because X has the Xv interface for this.
> 
> The other important bit is tiling.  That's easy enough to support in 
> something like VNC since it's rectangle based.  The one real missing
> bit is tile motion.  I would think you wouldn't get that with mjpeg
> anyway.
> 
> The other equally important piece is hardware scaling.  Obviously, if 
> you have a normal desktop resolution and are full screening an NTSC
> dvd, you can save a huge amount of bandwidth by supporting a scaled
> overlay.
> 
> I think adding both of these things to VNC would be pretty easy.  I 
> think the result would probably be better than a heuristic based
> mjpeg (simply because of the accelerated scaling).
> 
> Any thoughts on that?  Am I misunderstanding how the mjpeg works with 
> Spice and QXL?


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?

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.


> 
> > What you mean lack of guest visible rendering?, I might didnt
> > understand you
> >   
> 
> Sorry, I meant what Spice does with video memory (that it doesn't
> render a bitmap until the guest tries to read video memory).  If I
> understood that correctly, it sounds very interesting.  Again, I'd
> love to see the perf details around that.
> >>>> 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.
> >   
> 
> If the z-order of the window is such that one window is not
> displayed, then it's contents will not be rendered.  In Windows,
> individual windows only receive a WM_PAINT message with the visible
> region.  Not all apps clip accordingly of course.
> 
> For X, only windows that are visible receive expose events and again, 
> they're given a clipping region with what is actually displayed.
> 
> 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?

> 
> >> 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?
> >   
> 
> A lot of the things in Spice (from a quick glance at the spec) are
> too high level for just an X driver.  For instance, there are glyph
> based operations presumably for text rendering.  There are also brush 
> primitives.  While X has some support for these things, it's so old
> and broken that in modern applications, most toolkits just render to
> a local buffer, and then do a draw the image to the window.  That
> means the X server has no visibility into the fact that you're
> actually rendering text which means an X driver cannot take advantage
> of that information.


Well any driver can use what ever spice commands it want, the X driver
doesnt have to use all the spice commands, what is so bad about that?

Spice is not protocol for just windows or X or whatever, it id display
protocol that implment common display commands that can be used over
every display system.

> 
> > Spice driver to X (I mean from the X prespective on things) is just
> > another display driver.
> >   
> 
> What's the performance compared to the Windows driver?
> 
> >>> 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?
> >   
> 
> libc is not a plugin.  It implements very well defined behaviors that 
> have well understood behaviors.  Also, glibc generally does not crash 
> :-)  I would not want a user to replace glibc with a different libc.
> 
> Regards,
> 
> Anthony Liguori