Yes, put a breakpoint on the GetDIBits() call, go to the memory location of your buffer, in the debug windows, then watch the function fill it with 32 bits pixels.

EDIT: I suggest adding this line to the code:

// Release the bitmap handles
if(SelectObject(s_hdc, hbmp)){
DeleteObject(hbmp);
DeleteDC(s_hdc);
}

ReleaseDC(hDesktopWnd, hdc); // <- This line...

It doesn't seem to matter, but i think it's better that way.

Unfortunately, no, but i've found by creating a test project and testing different part of my algorithm, is that the xor pass is much faster than generating the screenshot pass, converting it pass, and compressing it. I think that's 3 copy all in all, and 5 buffers. Probably because im xoring a whole 32 bits at the time instead of bytes, and xor is a very cheap operation for the cpu. I used my own custom buffer class for this so my buffers are only allocated if the size requested is bigger than it was for the previous frame, so it rarely allocate memory after the first 2 screenshots (and prevent any leaks).

In fact, for the xor pass, im using 2 buffers, with 2 pointers to each of those buffers. Then, after each frame, i swap the 2 pointers, so the "back" buffer become the "front" buffer and vice versa, just like opengl does when double buffering, that could save you a copy.

Here's the result. It does the test 200 hundred times and average the results for better accuracy. Result are in seconds.

Not bad, 20 frames per seconds on average.

Bitmaps are stored with the y axis reversed, so that's why it's flipped vertically only. You might have to flip the r and b components too.

Thx for pointing that out. Im rebuilding my project almost from scratch so i can't test it right now though...