Lots of SetPixel's are slow, so how do games do it?

[D.V.D]

I made a simple function to see how fast my cpu can draw a decent chunk of the screen a certian color. The thing I found out is, using the SetPixel function to do it is extremely slow. So how do games do it? How is drawing a bitmap any faster than setting the pixels?

void drawlots(HDC hdc) {
	COLORREF col=RGB(0,0,0);
	for (short i=0; i<1000;i++){
		for (short y=0;y<500;y++) {
			SetPixel(hdc,i,y,col);
		}
	}
}

 

[s3rius]

There's a ton of reasons why this is slow:

First of all, this little piece of code means you're running SetPixel() 500,000 times! Calling a function and passing all the parameters to the callee take a little bit of time in itself. The program needs to allocate some stack memory, copy over all data, jump to the point in memory where your function is at (which wastes CPU cycles by cache trashing because of the jump), do all it's work and jump back to the caller's memory point again.

Second, SetPixel does more than just flip a few bits, it'll need to get the screen data linked to that device context and check if the given coordinates are within it's bounds, then release the data again. Everytime you call this function it'll have to do this over and over again.
SetPixel also returns a value (the color that's been drawn) and even though you don't do anything with the value it'll still slow down your program.

The actual "drawing" (meaning the modification of the memory bits where the screen pixels are stored in) is very fast.

If you draw a bitmap you're passing the entire picture in one swoop instead of doing all this ugly labor again and again.

It might even be worse. I don't know how SetPixel() works internally, but if it directly communicates with your graphics card that's another bottleneck. CPU is very slow in comparison to a GPU. That means every time the CPU sends data the GPU is stalled.

In games, one of the most important things to make stuff fast is to streamline data into your GPU smoothly. You try to let the GPU work a lot because it's so friggin fast and to only send data to it when necessary.
If you want certain changes to images then there's often shaders (which are used by the GPU - so it's fast) or other trickeries.

But there are ways to change each pixels without SetPixel.
I found this link for example

 

[D.V.D]

Interesting Ill check the link out. Oh I see why its slow. And I realize its 500 000 calls but loading a desktop background thats full 1080p would result in over 2 million calls to modify every single bit on the computer screen to the image. Yet its done fairly quickly. I also found some info on programming on the GPU. Working with shaders doesn't give you full control over your GPU the same way programming on your CPU gives you full control. Using opencl or in my case CUDA, you can create programs that run across hundreds of cores and even more threads. I was planning to try that out but Im having trouble getting it to work with visual studio C++.

 

[camelCase]

You have hundreds of cores in your computer? o.0

 

[D.V.D]

In your Gpu. Look at the specs for a GTX 460 or 570, they have 448 cores but they're not clocked as high as CPU cores.

 

[s3rius]

And I realize its 500 000 calls but loading a desktop background thats full 1080p would result in over 2 million calls to modify every single bit on the computer screen to the image. Yet its done fairly quickly.

That's because you don't load each pixel individually, but in bunches. Displaying a 40x40 image on your screen doesn't invoke the SetPixel function 1600 times. Instead the entire pixel data is taken and drawn in one fell swoop.

void print(int i){
    cout << i;
}

void main(){
    int[] array = {1,6,4,2,7}

    for(int i=0; i<array.length; ++i){
        print( array[i] );
    }
}

void print(int[] arr){
    for(int i=0; i<arr.length; ++i){
        cout << arr[i];
    }
}

void main(){
    int[] array = {1,6,4,2,7}

    print( array );
}

Look at those two pieces of pseudo code. They're both doing the same, but the first one invokes print 5 times. The second piece of code would be slightly faster because it saves 4 out of these 5 calls. Calling functions takes time too.

Of course the difference in this example would be negligible, it won't even be measurable. But when the difference is 1 to 500,000 it suddenly grows. And as I said, that's only one part where SetPixel would be slow.

You're right that the GPU isn't as programmable as the CPU, but that comes with it's power. The reason our CPUs aren't as powerful as our GPUs is because they need to be much more flexible. Flexibility comes with a price. Otherwise there wouldn't be a reason to replace your CPU with a GPU :3

When working with anything to display you generally try not to use things like SetPixel but you try to process as much data at once as you can. I brought shaders up because they can be used to modify your scene in ways where you might want SetPixel for (e.g. recoloring). If you really need to set a lot of single pixels you generally look for a trick around that.
E.g. put all the single pixels into a transparent image and display the entire image (or parts of it).

 

[D.V.D]

Oh I see, so what if I set pixel data of a bitmap and then just draw the bitmap. Would that technically be slightly faster or would it still carry the problems that using mass SetPixel's would because you would be pretty much calling mass SetPixel's on a bitmap instead of the HDC. The reason why I want to modify each pixel separately is for a attempt later on making voxels

 

[s3rius]

Drawing bitmap data would probably be a good chunk faster, yes.

A bitmap isn't much more than a chunk of rawr RGB values, so their modification isn't very complex. But as explained in the link in my first post there might need to be some padding depending on the image size. Also it might store pixels in RBG and not RGB..

 

[D.V.D]

Ill use the windows bitmap, it should use COLORREF values so RGB ill check however and see how fast it turns out.