On 11.12.2009, at 22:13, Izik Eidus wrote: > On Fri, 11 Dec 2009 14:46:55 -0600 > Anthony Liguori <anth...@codemonkey.ws> 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