On 11.12.2009, at 22:13, Izik Eidus wrote:
On Fri, 11 Dec 2009 14:46:55 -0600
Anthony Liguori<address@hidden> wrote:
Izik Eidus wrote:
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?
What I'm trying to understand is, what can we do with Spice that we
couldn't possibly do with vnc. That means understanding each feature
and then figuring out if there's a vnc analog.
If there are compellingly unique features to Spice that can't be
duplicated in vnc, then it's a no brainer. If you can do most things
in vnc but it would be hackish whereas Spice makes it all elegant,
then provided we can merge Spice without a huge amount of pain, then
it's a net win.
However, if we need to make a few changes to vnc in order to get the
same performance as Spice, then it's not quite as clear that it's
what we should be using.
We're talking about a major change here. There is a ton of
management software that assumes vnc today. Even though there are
Spice clients out there, there are embedded vnc clients in certain
tools today along with java applets.
That's not to say we shouldn't embrace Spice, we just have to make
sure we have a good reason to.
Ok, I understand your concerns.
But even though that spice and vnc achive in the end of the day the
same thing - they both allow remote rendering, they have fendumental
diffrent architacture.
Spice server work with a ring to the guest, it was build from day one
to work like that, In addition it was built from day one so that the
server will render only what it must to render (to allow much higher
virtualization denticity).
The ring is from qemu<-> guest, right? I mean, qemu<-> client would be a TCP
transport anyways, so the ring argument is void.
Just to make clear how much spice is diffrence from VNC is by the fact
that only the library itself (not including the drivers) have 128,277
lines of code inside it. (In my old qemu repo i see almost 600,000
lines for qemu) so this should give better prespective on how much
spice is diffrent from vnc.
So ofcurse in theory you can take all this 128,000 lines and push them
into qemu-vnc.c ?, but you got to remember that spice is not just
specific qemu thing, Spice should be used to work on physical machines
too, just cutting all this lines of code from spice and throw it into
qemu-vnc.c will be meaning a fork of spice inside qemu....
I definitely understand your point of having a single protocol. The good news
is that your physical machine stuff isn't released yet (AFAIK), so luckily
there's still time to change parts of the protocol :-).
It isnt just the rings and the rendering style that make spice
diffrence, it is the channels it have for each compoment, it is the
multiple drawing surfaces, and so on...
These should be fairly easy to implement in VNC too. In fact, I remember a
project implementing off-screen drawing in VNC using a larger region of the
screen than what was visible and then copyrect them in.
This why the VDI interfaces were made, it was made so who ever used
VNC, can still use it, whoever want to use SPICE can still use spice,
By merging SPICE you just merge VDI interfaces, not the library
itself, it is so self contained thanks to the VDI interfaces, that it
almost dont touch anything inside qemu, I belive this was one of the
best aurgoments when Avi pushed kvm into the kernel - the fact that it
was a module that can be easyly removed if ppl dont want to use it.
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.
Okay, I suspect we're in agreement here then.
Thanks God ! ;-)
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.
Well, in fact VNC would wait for the refresh timer of the VGA framebuffer dirty
thing and only send a single update too.
But Anthony's point was that rectangle drawing isn't used anymore. Instead gtk/qt just
draw it themselves and tell the X driver "here's an image".
Alex