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: Anthony Liguori
Subject: Re: [Qemu-devel] Spice project is now open
Date: Fri, 11 Dec 2009 13:30:22 -0600
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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.

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.

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?

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

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.

Regards,

Anthony Liguori




reply via email to

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