From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FeCbr-0006Lh-U2 for qemu-devel@nongnu.org; Thu, 11 May 2006 10:57:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FeCbr-0006LV-8W for qemu-devel@nongnu.org; Thu, 11 May 2006 10:57:47 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FeCbr-0006LS-4T for qemu-devel@nongnu.org; Thu, 11 May 2006 10:57:47 -0400 Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.52) id 1FeCdN-00011F-P5 for qemu-devel@nongnu.org; Thu, 11 May 2006 10:59:22 -0400 Message-ID: <446350E8.2040300@gmx.de> Date: Thu, 11 May 2006 16:57:44 +0200 From: Oliver Gerlich MIME-Version: 1.0 Subject: Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC References: <9893291.1147284983406.JavaMail.root@eastrmwml06.mgt.cox.net> <44626397.5090607@bellard.org> <200605110133.48808.paul@codesourcery.com> <44633670.2040203@medsci.uu.se> In-Reply-To: <44633670.2040203@medsci.uu.se> 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 Dan Sandberg wrote: > Paul Brook wrote: > >> On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: >> >> >>> In order to stop the release of incomplete BGR patches, I am >>> implementing a more complete patch. I am just adding depth = 32 with BGR >>> instead of RGB. If other pixel formats are wanted, you should signal it >>> now. >>> >> >> >> I don't have any paticular favourite pixel formats, but qemu now has >> [at least] 3 different sets of low-level pixel conversion routines >> (vga, tcx and pl110). If you're feeling really enthusiastic it would >> be nice if they could be unified :-) It's one of the things I've been >> meaning to look at when I've nothing better to do, but haven't got >> round to yet.. >> >> Paul >> >> >> >> _______________________________________________ >> Qemu-devel mailing list >> Qemu-devel@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/qemu-devel >> >> >> Hi, some comments on your suggestions: > Just curious... > > Are you using an OpenGL directdraw surface for the graphics emulation in > Qemu? > If not, then consider the benefits: > 1. It is much faster than any native graphics 2D/3D primitives like > Windows GDI Not sure how much faster it is on Windows; currently Qemu uses plain SDL for drawing which probably uses DirectDraw under Windows. However, AFAIK under Linux SDL is not hardware accelerated in most cases, while OpenGL could give hardware acceleration. > 2: It gives full control over things like window or fullscreen mode in > any (almost) resolution and color depth. AFAIK the windowing/fullscreen stuff is not done by OpenGL itself, but by some external library; SDL offers this functionality, GLUT is another possibility, and apparently the GlScene lib you mentioned does this as well. > 3. It is operating system independent. > 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha > channel etc in hardware, all you have to do is select the pixelformat > you like to use for the buffer and OpenGL does the rest - lightning > fast, minimum CPU-load. Basically, that sounds like a good idea to me. > > My suggestion would be to write a frontend similar to VMware's for Qemu > in Lazarus. Why Lazarus? > 1. The fantastic GLscene is available for Lazarus making > OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ > 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and > directly compileable for most operating systems without need for > modifications. > > Hope someone likes the idea, otherwise I will have to do it myself if I > can find some spare time. > > Dan Before you start working on this, I have some suggestions as well: Is the drawing part really a performance bottleneck? And will this really be improved by changing the drawing functions, or wouldn't a better graphics card emulation give much more improvements? What does a profiler say about this? I seem to recall that in most cases, SDL doesn't slow down performance in Qemu. It might be interesting to see how much the new RGB<->BGR conversions costs, though. Another thing that I think is important is that not all computers have OpenGL acceleration. And at least on Linux, software OpenGL rendering is quite slow, so a port to OpenGL would probably be a huge drawback for some people. If OpenGL is really worth the trouble, one could add OpenGL rendering so that people can still use the "old" way of drawing if no hardware acceleration is available. A GUI frontend would be quite nice, I think. So far several people have submitted (quite useful) patches for this, but nothing more has happened in that direction. Not sure what is required for a GUI that will be integrated into Qemu finally... Thanks, Oliver