Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC

[Oliver Gerlich]

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
> > address@hidden
> > 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