From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kcq0T-0004L1-AR for qemu-devel@nongnu.org; Mon, 08 Sep 2008 19:18:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kcq0Q-0004Km-RQ for qemu-devel@nongnu.org; Mon, 08 Sep 2008 19:18:51 -0400 Received: from [199.232.76.173] (port=48008 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kcq0Q-0004Kj-KZ for qemu-devel@nongnu.org; Mon, 08 Sep 2008 19:18:50 -0400 Received: from mx1.redhat.com ([66.187.233.31]:50705) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kcq0P-0007A8-LP for qemu-devel@nongnu.org; Mon, 08 Sep 2008 19:18:50 -0400 Date: Tue, 9 Sep 2008 00:18:43 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window Message-ID: <20080908231843.GA29606@redhat.com> References: <20080905120214.GD1373@shareable.org> <48C16207.5090808@eu.citrix.com> <20080905165536.GA12606@redhat.com> <48C168CE.5040700@eu.citrix.com> <48C348D3.6070702@codemonkey.ws> <20080908134140.GF4947@shareable.org> <20080908134833.GQ2315@redhat.com> <48C53D24.8030803@redhat.com> <20080908150759.GB8465@shareable.org> <20080908154700.GT2315@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080908154700.GT2315@redhat.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org On Mon, Sep 08, 2008 at 04:47:00PM +0100, Daniel P. Berrange wrote: > On Mon, Sep 08, 2008 at 04:08:01PM +0100, Jamie Lokier wrote: > > Gerd Hoffmann wrote: > > > Beside that I still think it would be a good idea to separate qemu and > > > the gui into two separate processes, so you can close the GUI window and > > > keep the VM running. It also solves the dependency issue for distros as > > > the gtk frontend with all the dependencies can just go into a separate > > > sub-package. > > > > Extending VNC with a "shared memory" extension, similar to Xlib's > > MIT-SHM extension, and implementing it in QEMU and Gtk-VNC would be a > > nice way to do this. > > Funny you should mention that. Anthony had code todo exactly that against > for both QEMU and GTK-VNC a while back. We had it in the GTK-VNC for a > short while but removed it due to some race conditions in its impl, and > it interracted badly with our OpenGL impl. We could easily revisit this > idea if it were thought to be important / useful. Just thought I'd mention one other thing - it is not actually clearcut / or guarenteed that XShm + VNC would improve performance in all circumstances. This is because X pixmaps created via XShm apparently cannot live in video memory, and thus it is not so easy to get full performance advantage of hardware acceleration - this could impact scaling for example. The need to perform XSync operations when updating the pixmaps may also negate the benefit of avoiding the socket I/O. It would all depend on the size of the updates vs frequency of them. Still defintely worth a try to see what kind of difference Shm makes in a real world scenario with QEMU. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|