Is there a way to change the color of a specific pixel in C++? I've made an example project where I used graphics.h's bar to change every pixel on the screen:

#include <graphics.h>

int main( )
    initwindow(600, 600, "Example");
    for (int x = 0; x <= 600; x++) {
        for (int y = 0; y <= 600; y++) {
    while (!kbhit( ))
    return 0;

But this takes way to long like maybe 30 seconds. I was wondering if there was a way to do it faster, under a second. btw I'm using dev-c++.

  • \$\begingroup\$ That run code snippet option only works for javascript/HTML code, so I removed it. \$\endgroup\$
    – glampert
    Commented Aug 25, 2015 at 2:07
  • \$\begingroup\$ Can you explain why you want to fill the viewport with individual pixels? It might help to give you better answers. If you are just stress testing, then you should know that there are better ways to fill the screen and in normal circumstances when drawing individual pixels you will only be drawing to a small fraction of your viewport so drawing individual pixels to fill the screen is not a very realistic test of the pixel drawing abilities. \$\endgroup\$ Commented Aug 25, 2015 at 16:28

2 Answers 2


You could try putpixel (void putpixel(int x, int y, int color))

Although I'm not really sure that's going to be fast enough. You're using <graphics.h> which is a very old library designed for when many computers were running DOS and had resolutions like 320x200 - a quarter of your target. On Windows it would be using GDI under the hood, not exactly the fastest option.

If you want to stick with this library, try to use shape drawing or image drawing routines as much as possible, and avoid single pixel drawing.

There are a few suggestions on more modern graphics libraries here, which you ought to learn instead: https://stackoverflow.com/q/7860569/2038264

  • \$\begingroup\$ Putpixel was faster but it still took about 4 secs so ill try GDI and see if that helps. \$\endgroup\$
    – Funshine
    Commented Aug 25, 2015 at 2:38
  • \$\begingroup\$ @Funshine no don't use GDI; GDI is what it's using behind the scenes and besides it's not the easiest library to use. Please check out the linked question at the end. \$\endgroup\$ Commented Aug 25, 2015 at 2:46
  • 2
    \$\begingroup\$ No PutPixel method in any API is going to be fast enough to fill the whole screen. The only option to do that with any efficiency (on the cpu) is to get dirty and poke the pixels to the image with low level memory manipulation. Then you can make it much more efficient by optimizing for cases where you are filling whole lines or blocks at a time. If you want to draw every other pixel though, for example, you are out of luck and will have to resort to shaders on the GPU. Or reduce your resolution. \$\endgroup\$ Commented Aug 25, 2015 at 2:55

First of all

Do not use that deprecated library ( unless you know why you r using it eg. For assignments)

You want fast graphics but the problem here is the old drivers used on a modern machine. For the fast rendering you should prefer either directx(only on windows) or opengl(available on multiple platforms).

If you choose to use opengl then go to nehe's tutorials and there you can start understanding the modern libraries.

In opengl putPixel sets pixels on screen w.r.t array provided

  • \$\begingroup\$ openGL PutPixel is even slower than just doing it in software and then uploading the texture to the GPU. Not only are you still poking pixels, you are sending them to the GPU. It's fast enough if you are only doing some basic drawing (like put a circle on the screen) but filling a texture would be quite inefficient. \$\endgroup\$ Commented Aug 25, 2015 at 15:43
  • \$\begingroup\$ @FuzzyLogic i am talking in the sense that "But this takes way to long like maybe 30 seconds. I was wondering if there was a way to do it faster" opengl's put pixel doesnot take 30 secs. here we dont want to max out FPS. we just need to make that 30 secs lesser \$\endgroup\$ Commented Aug 25, 2015 at 15:46
  • \$\begingroup\$ I think Funshine modified his question. it did say he wants to do it in under 1sec. Or another question of his. Anyway, it's still slower than just doing it in software. The only way to optimize it in openGL is to draw to a texture, otherwise you are sending a sparse array of pixels to the GPU every frame. With a filled screen, drawing to texture would be faster, it's only one upload. \$\endgroup\$ Commented Aug 25, 2015 at 16:07
  • \$\begingroup\$ Actually, it does still say to get it under 1 sec. I missed it too, until I scanned the question again :) \$\endgroup\$ Commented Aug 25, 2015 at 16:15
  • \$\begingroup\$ also i know that but in process of explaining him (still using graphisc.h) he would not understand about texcoord2f , vertex2f , projectionmatrix ( ortho) , modelview matrix (identity) etc. etc.. so in short and easy way to explain him was put pixel \$\endgroup\$ Commented Aug 25, 2015 at 16:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .