From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Feah9-0003ud-0W for qemu-devel@nongnu.org; Fri, 12 May 2006 12:40:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Feah7-0003uI-66 for qemu-devel@nongnu.org; Fri, 12 May 2006 12:40:50 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Feah7-0003uF-2A for qemu-devel@nongnu.org; Fri, 12 May 2006 12:40:49 -0400 Received: from [195.252.0.52] (helo=zebra.uas.se) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Feais-0007f8-Od for qemu-devel@nongnu.org; Fri, 12 May 2006 12:42:39 -0400 Received: from [127.0.0.1] ([195.252.0.249]) by zebra.uas.se (PMDF V6.0-24 #39208) with ESMTP id <01M2CEZV4MHQ000BN1@zebra.uas.se> for qemu-devel@nongnu.org; Fri, 12 May 2006 18:40:43 +0200 Date: Fri, 12 May 2006 18:40:43 +0200 From: Dan Sandberg Subject: Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC In-reply-to: <20060512155317.GD4310@mail.shareable.org> Message-id: <4464BA8B.9040801@medsci.uu.se> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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> <20060512132601.GB25118@mail.shareable.org> <4464AB9B.9030107@medsci.uu.se> <20060512155317.GD4310@mail.shareable.org> 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: >Dan Sandberg wrote: > > >>When the screen is "painted" the DAC's read from the host video buffer >>(1600x1200) and interpret it as RGB. Somewhere they "hit" the left >>boundary of the separate viewport that you have set up and bang, on the >>fly they switch to reading 800x600-organized data from the other video >>buffer and interpreting it as BGR. Later on the same video line they >>"hit" the right boundary of the separate viewport and bang they switch >>back to reading from the main buffer and interpreting it as RGB. >> >>As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are >>equally active and equally often updated on the same physical screen - >>without need for any moving data around, and without any time consuming >>activity at all taking place as all switches are done on the fly in the >>background by special hardware (if the board supports this). >> >>It is like having two separate physical video boards, each with its own >>display buffer. >> >> > >Thanks; I didn't know OpenGL had that function as well as 3d rendering. > >That's what the Xv extension does ("X video") - it's to provide an >overlay to be used by video players. Xv scales the source image and >mixes it with the primary framebuffer in the way you describe. >However, Xv is intended for non-RGB colourspace source formats, so may >not be suitable for Qemu. I don't know if Xv sometimes can support RGB. > >Since Xv is supported by many video cards, even old ones without 3d, >or without working 3d drivers, I'm surprised that particular OpenGL >function isn't commonly implemented with equal performance. > >-- Jamie > > >_______________________________________________ >Qemu-devel mailing list >Qemu-devel@nongnu.org >http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > Oooops, I just took a look at a list of OpenGL pixelformats. I really thought I had seen BGR there, but I was wrong. Again I am new to OpenGL so do not take anything I say for the truth. Here is the list: GL_ALPHA, GL_ALPHA4, GL_ALPHA8, GL_ALPHA12, GL_ALPHA16, GL_LUMINANCE, GL_LUMINANCE4, GL_LUMINANCE8, GL_LUMINANCE12, GL_LUMINANCE16, GL_LUMINANCE_ALPHA, GL_LUMINANCE4_ALPHA4, GL_LUMINANCE6_ALPHA2, GL_LUMINANCE8_ALPHA8, GL_LUMINANCE12_ALPHA4, GL_LUMINANCE12_ALPHA12, GL_LUMINANCE16_ALPHA16, GL_INTENSITY, GL_INTENSITY4, GL_INTENSITY8, GL_INTENSITY12, GL_INTENSITY16, GL_R3_G3_B2, GL_RGB, GL_RGB4, GL_RGB5, GL_RGB8, GL_RGB10, GL_RGB12, GL_RGB16, GL_RGBA, GL_RGBA2, GL_RGBA4, GL_RGB5_A1, GL_RGBA8, GL_RGB10_A2, GL_RGBA12, or GL_RGBA16 Anyway, many people think of OpenGL as just 3D, but it is extremely competent for 2D (given a good driver). If you want an example of OpenGL superior 2D performance compared to Windows GDI routines, then go to http://www.skinhat.com/lazarus/ and download Lazarus from there with GLscene preinstalled. (You probably also need to download and install FreePascal from: http://www.lazarus.freepascal.org/) (If you do not have OpenGL drivers installed you have to get them from your graphic card manufacturer's homepage.) There are a large number of OpenGL examples included complete with source code ready to compile and test. Open the example project glscene/demos/bench/canvas/canvas.lpr and compile and run by hitting the green arrow. Windows GDI performance look really bad in comparison. On my computer the 20.000 ellipses test with a line width of 2 took 2268 ms for standard Windows GDI and 145 ms for the OpenGL 2D-canvas (and its just a standard business computer with no fancy graphic card at all). There are many other nice examples included as well, so it is well worth the download. Regards Dan