2

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?

cYrus
  • 2,976
  • 6
  • 29
  • 47
  • 2
    Did you ever find a good solution? I am having the same problem. I want to manually draw each pixel of 1920x1080p frames, can't figure out a fast way to do it. – Myforwik May 04 '12 at 04:43
  • Yes, the best approach seems to be an OpenGL texture as [the accepted answer](http://stackoverflow.com/a/4288283/477168) suggests. – cYrus May 04 '12 at 09:48
  • I suspect that SDL itself isn't the bottleneck, but rather X11. I'm assuming you're running X, so since SDL is an abstraction layer, it converts the SDL pixel manipulations to use the X11 backend which is the source of the latency. Try executing SDL on a machine without X, and you'll notice it run considerably faster since it'll now be printing directly to the Linux framebuffer. – Vilhelm Gray Jul 17 '13 at 13:44

3 Answers3

4

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.

hotpaw2
  • 70,107
  • 14
  • 90
  • 153
  • 2
    Dense. I'll make a try with the OpenGL texture. But there's something still quite obscure to me, it's not so strange to repaint the whole screen, for example dragging this browser window around. Why do things get complicated when I'm trying to perform such repaints in my own application? (sorry about the dumb question) – cYrus Nov 26 '10 at 20:35
  • I eventually accept unportable solutions, but the ease of setup for the end user is mandatory. – cYrus Nov 26 '10 at 20:37
  • 1
    +1: Using an `OpenGL` texture along with a `PBO` seems to be the best choice. Thanks. – cYrus Nov 30 '10 at 20:40
1

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.

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • I don't do that, what you're saying is double buffering, right? Tried that with `SDL` and `xlib`, it improves the whole thing but it's not enough. – cYrus Nov 26 '10 at 20:33
0

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.

BЈовић
  • 62,405
  • 41
  • 173
  • 273
  • 6
    `SDL` and `xlib` are far away from being window managers. Surely it's not their main feature. – cYrus Nov 30 '10 at 20:36
  • @cYrus Hmmm got a link that can back up that statement? I know that (for example) SDL can do audio, and xlib can display windows on remote server, but their main feature is managing windows. – BЈовић Nov 30 '10 at 20:54
  • 1
    From www.libsdl.com: « 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." » – cYrus Nov 30 '10 at 21:55
  • 2
    `xlib` acts as interface to the X server. From en.wikipedia.org/wiki/X_server: « X provides the basic framework, or primitives, for building such GUI environments: drawing and moving windows on the screen and interacting with a mouse and keyboard. X does not mandate the user interface — individual client programs known as window managers handle this. As such, the visual styling of X-based environments varies greatly; different programs may present radically different interfaces. X is built as an additional (application) abstraction layer on top of the operating system kernel. » – cYrus Nov 30 '10 at 21:56
  • 1
    `Xlib` is _not_ a window manager. It's a C API to the `X Window System`. The `X Window System` is _not_ a window manager. It's a "graphics server" (whatever that is). – étale-cohomology Dec 25 '16 at 13:41