Fast pixel drawing library

Question

My application produces an "animation" in a per-pixel manner, so i need to efficiently draw them. I've tried different strategies/libraries with unsatisfactory results especially at higher resolutions.

Here's what I've tried:

• SDL: ok, but slow;

• OpenGL: inefficient pixel operations;

• xlib: better, but still too slow;

• svgalib, directfb, (other frame buffer implementations): they seem perfect but definitely too tricky to setup for the end user.

(NOTE: I'm maybe wrong about these assertions, if it's so please correct me)

What I need is the following:

• fast pixel drawing with performances comparable to OpenGL rendering;

• it should work on Linux (cross-platform as a bonus feature);

• it should support double buffering and vertical synchronization;

• it should be portable for what concerns the hardware;

• it should be open source.

Can you please give me some enlightenment/ideas/suggestions?

Answer 1

Looks like you are confusing window manager (SDL and xlib) with rendering library (opengl).

Just pick a window manager (SDL, glut, or xlib if you like a challenge), activate double buffer mode, and make sure that you got direct rendering.

What kind of graphical card do you have? Most likely it will process pixels on the GPU. Look up how to create pixel shaders in opengl. Pixel shaders are processing per pixel.

Answer 2

I'm not totally sure what you're doing wrong, but it could be that you are writing pixels one at a time to the display surface.

Don't do that.

Instead, create a rendering surface in main memory in the same format as the display surface to render to, and then copy the whole, rendered image to the display in a single operation. Modern GPU's are very slow per transaction, but can move lots of data very quickly in a single operation.

Answer 3

Are your pixels sparse or dense (e.g. a bitmap)? If you are creating dense bitmaps out of pixels, then another option is to convert the bitmap into an OpenGL texture and use OpenGL APIs to render at some framerate.

The basic problem is that graphics hardware will be very different on different hardware platforms. Either you pick an abstraction layer, which slows things down, or code more closely to the type of graphics hardware present, which isn't portable.