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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel