From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FeXeh-00037p-FG for qemu-devel@nongnu.org; Fri, 12 May 2006 09:26:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FeXeg-000372-GY for qemu-devel@nongnu.org; Fri, 12 May 2006 09:26:06 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FeXeg-00036y-CL for qemu-devel@nongnu.org; Fri, 12 May 2006 09:26:06 -0400 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FeXgQ-0005LH-EE for qemu-devel@nongnu.org; Fri, 12 May 2006 09:27:54 -0400 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id k4CDQ1uY029301 for ; Fri, 12 May 2006 14:26:01 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id k4CDQ1RT029291 for qemu-devel@nongnu.org; Fri, 12 May 2006 14:26:01 +0100 Date: Fri, 12 May 2006 14:26:01 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC Message-ID: <20060512132601.GB25118@mail.shareable.org> References: <9893291.1147284983406.JavaMail.root@eastrmwml06.mgt.cox.net> <44626397.5090607@bellard.org> <200605110133.48808.paul@codesourcery.com> <44633670.2040203@medsci.uu.se> <4463AF2E.6020401@bellard.org> <446448F9.70001@medsci.uu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <446448F9.70001@medsci.uu.se> 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 Dan Sandberg wrote: > Creating a rectangular direct output area in OpenGL is actually like > vitualizing a graphics card. That is what X's XF86DGA ("Direct Graphics Adapter") feature does. And I believe SDL already supports XF86DGA when in full screen mode. > It is updated at native speed Not necessarily. When I tried using mplayer (a video player) with the video output set to use OpenGL, it was the slowest of all options - even slower than writing the images though X11 shared memory with a copy-to-screen bitblt for each frame. But then, OpenGL drivers vary considerably in their performance and quality. > and you can select pixelformat for that > area independent of the host pixel format and you do not have to be > doing any RectangleBlit operation or causing any CPU-load - to my > understanding at least. Well, OpenGL does a RectangleBlit each time it redraws the 3d rendering area, doesn't it? If you have hardware accelerated OpenGL support, that shouldn't use much CPU. But then, the same is true for old-fashioned hardware accelerated 2d bitblt, if the pixel format is supported. > [...] I am not saying that any of todays possibilities in Qemu > should be retired, rather that it could be sort of a new plug-in > module for those who want a virtual display adapter with close to > native graphic performance and happen to have what is needed in > terms of graphic card and drivers. I agree it's worth a look, because it may be faster for some people, and because it provides access to image scaling (potentially hardware assisted), which classic X11 bitblt does not. It might be worth looking at mplayer's OpenGL driver, which does something similar to what Qemu would need. Other X features which can do similar things and may provide equal or better performance are: Xv (used to display video, but generally provides a resizable overlay; may or may not provide a usable pixel format), and Xrender. -- Jamie