From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJEGA-0007Xo-5a for qemu-devel@nongnu.org; Fri, 11 Dec 2009 17:46:50 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJEG5-0007WP-9n for qemu-devel@nongnu.org; Fri, 11 Dec 2009 17:46:49 -0500 Received: from [199.232.76.173] (port=56324 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJEG5-0007WM-4m for qemu-devel@nongnu.org; Fri, 11 Dec 2009 17:46:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1025) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJEG4-0007KX-Ig for qemu-devel@nongnu.org; Fri, 11 Dec 2009 17:46:44 -0500 Date: Sat, 12 Dec 2009 00:46:35 +0200 From: Izik Eidus Subject: Re: [Qemu-devel] Spice project is now open Message-ID: <20091212004635.0b57a8c0@redhat.com> In-Reply-To: <8BF07900-1F21-4E1C-AFC7-FF9CC47525A3@suse.de> References: <1393046876.1549021260539141025.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <4B226BFC.1040606@codemonkey.ws> <20091211204828.464707cf@redhat.com> <4B2297A2.8040102@codemonkey.ws> <20091211212135.645864f9@redhat.com> <4B229DCE.7070500@codemonkey.ws> <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211222101.5e924d20@redhat.com> <4B22AFBF.6080709@codemonkey.ws> <20091211231334.3d8a599f@redhat.com> <8BF07900-1F21-4E1C-AFC7-FF9CC47525A3@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Yaniv Kamay , qemu-devel@nongnu.org On Fri, 11 Dec 2009 23:08:01 +0100 Alexander Graf wrote: > > On 11.12.2009, at 22:13, Izik Eidus wrote: > > > On Fri, 11 Dec 2009 14:46:55 -0600 > > Anthony Liguori 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