views:

656

answers:

6

I need a simple graphics C library to use on a device where I will be writing directly to the frame.

The frame is located in regular memory. There is no graphics acceleration hardware.

Nothing fancy. I just want to be able to draw lines, circles, OSD stuff like strings as well.

It would be nice to have functions that use good, lean algorithms (my CPU is an ARM9 running at 400MHz).

What are some recommendations for this?

A: 

OPenGL has a set of 2d functions, not sure if it is too bloated for you or if it can be trimmed down. It is written in C, at least.

tkotitan
+3  A: 

Cairo is pretty powerful and easy to use. I think Mozilla uses it as the basis for the <canvas> element and the SVG renderer.

eduffy
Yes, you are correct.
dirkgently
+1  A: 

From your requirements it appears you need something like an embedded framebuffer library (or whatever it is called). I played around with some of the following a few years back for an embedded browser (which didn't make it to the market). Unfortunately, I can't remember much to give you any analysis. Have a look:

  • DirectFB
  • GTK/X (or a port using directFB)
  • Cairo (as another poster has suggested -- this is very powerful)

Also, this article may be of interest.

dirkgently
A: 

Try SDL. From the web page:

Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."

Aaron Digulla
+4  A: 

For very simple needs (lines, circles, polygons, text) I have always just made my own. Check out bresenham's algorithm for lines and circles, Wu's modifications for antialiasing on circles and lines.

Gimp will output C code for images, which is what I do for fonts, and drawing them is pretty easy. I have used anti-aliasing (gimp --> grayscale, use the grayscale value as the alpha), but haven't done proportional fonts. They aren't much harder, and can make the display a bit nicer, but I haven't needed them yet.

Polygons are simply multiple lines, and filled polygons are quite fun to implement.

It's not a lot of work, and you'll grow from the experience.

If, however, you decide you want to render SVG or some other complex vector language, then a library is in order. But for simple things, this isn't complex.

Adam Davis
That little tidbit about Gimp is fascinating. I'm going to have to try that out. Thanks!
technomalogical
+4  A: 

I'd like to second OpenGL, especially the OpenGL|ES variant.

Here is a link to a Software based OpenGL-Renderer: http://sourceforge.net/projects/ogl-es

I've spend the last three years writing commercial software rasterization codes on ARM9 and similar processors, so I think I can comment on use of cairo and other high level APIs:

They work very well and are incredible powerfull, but on a target as limited as an ARM9 you will never be happy with the performance. The graphic libs are written with your typical Desktop PC in mind, and they trade precision for performance. This is nice for high quality SVG rendering, but to slow on a humble ARM.

The Vincent OpenGL|ES I've suggested above has a on the fly dynamic code generation engine for ARM-CPUs in place, so you get almost the performance of hand-optimized assembler code.

If you can limit yourself to just one bitmap-format, just two blend-modes and a hand full of rendering primitives you may get better performance by writing a dozen of render-routines yourself. Depending on your experience and requirements that can take anything from two days to a month though..

Nils Pipenbrinck