1

I have an application, which generates image. Each frame is completely different and can not be accelerated by using of textures or sprites.

I want to draw with high rate, but best I got with SDL is about 8 fps at 2560x1440 by using SDL's canvas.draw_point. I'd like to push it to 60 fps or more.

I feel I'm doing something wrong. What is the proper approach to this problem?

My 'computations' are on separate threads, so I can dedicate a whole thread to a simple copy from a memory array to (whatever technology requires).

I want to do it under X using Rust, so any X or cross-plaform library (including a pure C) is ok, but I feel that the problem is not within library, but in my 'per pixel' approach. How to do it right?

George Shuklin
  • 6,952
  • 10
  • 39
  • 80

1 Answers1

3

This is more of a general guideline than a concrete technique to optimizing drawing with SDL and X11 (I haven't worked with either), but I think it will be useful for you.

Never use point drawing routines to draw each pixel of an image. The CPU overhead is massive. If you are creating an image pixel-by-pixel, then what you should do is create your own image buffer (array) and draw into it by assigning to the array elements. (Your graphics API may have an “image”, “buffer”, or “raster” type for you to use for this purpose, or it may let you provide a plain array.) Then, once you have drawn all of your pixels (or as many as you want to draw in one frame), use the graphics API's “draw image” operation (or “upload texture”, if you're working with a 3D/GPU-oriented API), which will transfer the data in bulk to GPU memory.

That's the best you can do, assuming you're computing pixels using the CPU. The next level of optimization is to figure out how to rewrite your pixel computation so that it can run as a fragment shader on the GPU instead. This allows you to take advantage of the GPU's architecture optimized for image computations, and avoid the need to copy the entire image from main memory to GPU memory every frame. However, it typically requires redesigning your algorithm.

Kevin Reid
  • 37,492
  • 13
  • 80
  • 108