On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf <ag...@suse.de> wrote:
> > 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. Beside the fact that we dont have the network overhead... > > > 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. In theory you can even change the whole of VNC into SPICE or the whole of VI into EMACS, so???, I personaly think changing code isnt the problem, the problem is always the desgien, and SPICE have fandumental diffrent desgien than VNC, (Here you can say: OK I can make my VNC desgien like SPICE, or you can say I think SPICE dsgien is bad, or you can just use SPICE...) > > > 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. Yes but what will happen if you run vnc using paravirtual device? > > 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". And what about 3D ? or Xrender operations such as composing ? (streching)? > > Alex