1

I was working with a code to print pixels.

// C code

#include <graphics.h>
#include <conio.h>

int main()
{
    int gd = DETECT, gm;

     initgraph(&gd, &gm, "C:\\TC\\BGI");

     for (int i = 0; i < 100; i++)
     {
         for(j = 0; j < 200; j++)
         {
             putpixel(i, j, GREEN);
         }
     }

     getch();
     closegraph();
     return 0;
}

Is there any way of achieving faster response from C compiler while using putpixel() in this code? The speed with which console gets colored with the execution of putpixel() is pretty slow, so I was wondering if there was any other library which I could use to speed up the printing pixel process on the screen using C on a windows system or a Linux one?

Community
  • 1
  • 1
beginner
  • 281
  • 2
  • 13
  • Welcome to Stack Overflow. Question should not be requests for a library or software, as they can lead to spam and many opinion-based answers. – mginn Jun 01 '15 at 03:06
  • see [Graphics in C/C++](http://stackoverflow.com/a/21699076/2521214) as you are using BGI I cant help (did not use it for 2 decades) if you gonna use something more recent like GDI then simply create bitmap get the pointer to its lines and use them as any Array in C/C++. when done rendering copy the bitmap at once to visible area (like window,...) this is also called back buffering. But you are probably still using MS DOS environment so may be direct memory access + VESA will be better option if your OS does not limit your access to it – Spektre Jun 01 '15 at 07:54
  • `putpixel()` is not a standard C function; you need perhaps to be clear about the toolchain and library you are using. Are you using the genuine BGI library in a 16 bit Borland compiler (seems unlikely) or are you in fact using the WinBGIm Win32 emulation? Either way it will be relatively slow, WinBGIm is no more that a BGI API wrapper to Win32 GDI under the hood. – Clifford Jun 01 '15 at 08:35
  • Hi Clifford, I am using winBGIm Win32 one, not the genuine library. – beginner Jun 01 '15 at 18:32
  • Hi Spektre, Thank you. I"ll check that. What about this direct memory access + VESA, could you please give me an example or any link? – beginner Jun 01 '15 at 18:36

2 Answers2

2

I'm afraid the answer is almost always going to be "don't use putpixel()".

The problem is that it requires a lot of work to achieve so little (a one-pixel change!) and you have to do it tens of thousands of times before you've done anything useful.

In an ideal world you might hope for it all to be inlined and optimised down to what you really need, but if putpixel() handles many different screen formats (and from what I remember of BGI, it does) then that would require highly improbable degrees of inlining and loop unswitching.

What you want to do is to find a more high-level operation, like putimage(), or in your simple example bar(), which can achieve more with a single function call.

You probably want to move to something more performance-oriented like SDL, but you'll still have the same fundamental problem if you try to use a function call for every single pixel.

sh1
  • 3,914
  • 13
  • 28
1

putpixel() is pretty slow, no matter which framework or library you use. Try to create a bitmap and calculate the memory address of each pixel yourself.

Cross-platform frameworks that allow you to do such a thing are SDL and Allegro.

See also:

Aaron Digulla
  • 297,790
  • 101
  • 558
  • 777
  • Thanks Aaron. I don't have much experience in this field. Any example or link which should I refer while working on SDL? Another thing, without incorporating any cross platform framework, is there any way out for calculating memory address and printing a pixel? – beginner Jun 01 '15 at 18:41
  • Tutorials for SDL: http://lazyfoo.net/SDL_tutorials/ Direct access to memory is always hardware specific. There is no generic, cross-platform way to do that. But the main problem is to set up the graphics environment. That's thousands of lines of code - platform specific and on Linux, it depends on the distribution and the installed drivers and frameworks. – Aaron Digulla Jun 02 '15 at 08:14
  • I suggest that you download the source for SDL and have a look to see how much effort it would be to "simply" create a graphics context to render into. – Aaron Digulla Jun 02 '15 at 08:15