From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KctF7-0008Ld-9D for qemu-devel@nongnu.org; Mon, 08 Sep 2008 22:46:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KctF4-0008LR-Gz for qemu-devel@nongnu.org; Mon, 08 Sep 2008 22:46:11 -0400 Received: from [199.232.76.173] (port=54362 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KctF4-0008LO-Bc for qemu-devel@nongnu.org; Mon, 08 Sep 2008 22:46:10 -0400 Received: from ag-out-0708.google.com ([72.14.246.240]:50990) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KctF4-0005Bd-4z for qemu-devel@nongnu.org; Mon, 08 Sep 2008 22:46:10 -0400 Received: by ag-out-0708.google.com with SMTP id 31so5006908agc.5 for ; Mon, 08 Sep 2008 19:46:08 -0700 (PDT) Message-ID: <48C5E33E.7000802@codemonkey.ws> Date: Mon, 08 Sep 2008 21:45:18 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window References: <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> <20080908231843.GA29606@redhat.com> <20080909001044.GA18018@shareable.org> In-Reply-To: <20080909001044.GA18018@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Jamie Lokier wrote: > Daniel P. Berrange wrote: > >> 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. >> > > I haven't seen any scaling with VNC so far, but it would be nice sometimes. > It's been supported in gtk-vnc for a while now. > How does sending the image over the wire then asking the server to > scale it using RENDER improve on sending it over XShm then asking the > server to xscale the pixel using RENDER? Or is there something else > you can do when you don't use XShm? > The key point being you can avoid a copy even when using a shared memory extension because you don't necessarily have to back the shared memory with an XShmImage. Even if you have to copy from shared memory to a hardware framebuffer, you avoid copying the data to the kernel socket buffer. But copying data isn't super expensive assuming you're hitting the cpu cache (which you probably are). So I don't know how much it saves in real life. Regards, Anthony Liguori