Windows Screen Buffer

I havn't tested the code myself, so I don't know how fast it captures the screen, but it will probably be a good start (assuming that you use C++).
http://www.developerfusion.co.uk/show/1708/

To get the DC for the entire screen, you can call
GetDC(NULL);.

Also, you might check out the ZoomIn example that I believe is included with Visual Studio (if not you can download the VS6 version of the sample from MSDN). It shows how to get the desktop into a DC so you can do whatever you want with it.

However, like Enselic, I'm not sure how this method compares to the built-in screen capture. It may be exactly the same method Windows uses.

How about BitBlt () API function ?. I believe this is the fastest bit copy implementation you've got in Win32. I did some testing by copying a 640x480 region into memory repeatedly (1000 times) and got approximately 27 frames/sec. Is this sufficient ?.

My computer spec: P4 1.6 Gh, 512 MB of RAM, Windows XP.

There is an utility called AnimGet for grasping game sprites on the screen. You may contact the author if necessary.

Well guys thanx for ur help but u see I dont want to use the GDI functions .. These are very bad when performance is the key issue ... Not every1 uses the specification which my friend mentioned here ... Will Windows OS allow me to do its screen buffer(watever is called)... I did exactly the same thing in Assembly ... accessing Dos's Screen Buffer ... So can I do it in C++ .. I was told by some one to go and use Video Miniport ... thats related to Device Driver PRogramming ... Where can I ger help on it ... Any help on Video Miniport or Device Driver Programming for a start ...

Anyhow thanx guys for the help :D

I'm not aware of any hacking like that, but if Windows allows direct accessing to the video buffer then the desktop will be a total mess. The reason Windows has HDC is to limit each application from drawing outside of the device context it has. I've got some notes here:

Windows has provided you a way to get HDC of the whole desktop, that means it is the formal way to do this.

If you want a faster speed, then switching to Win32 ASM is a possible approach.

The real bottleneck is I/O functions you use to dumb the memory content to a file, try upgrading the file I/O functions than using these kind of hacks. Copying/moving memory is very fast.

I think the 3rd reason is the most important, btw, why 27 frames/sec is not sufficient ?. I wonder...

Well The 27 Frames/sec of 640 * 480 desktop screen with such specifications. I have got 256 Ram and use 1024 * 768 resolution. then he must be running one app at a time ... well i guess the result will be then very poor... So u Win32 ASM will help me ... Will I be able to access the Screen Buffer .. Well u see why cant simple access i.e. read-only access is not avaible ... if access was readonly then watever apprenhensions u have wud not exist since Screen Buffer wud not manipulated ... Anyways somebody any help on Video Miniports ???

Just out of curiousity, what kind of application are you writing?

As I said, the processing speed depends mostly on I/O operations. Let's just do some calculations:

I captured a 640x480x16 region and wrote them to a file with a loop of 400 times, the result is 27 fps. The amount of transfered data is:

640 (px) * 480 (px) * 2 (bytes) * 400 (times) ~ 234 MB

There were roughly 234MB had been transfered and wrote to a file in (400 / 27) = 15 secs. So, the transfer rate is: 15.6 MB/sec.
---> You may try copying a large file to somewhere in the same hard drive, this speed is not easy to archive, the normal transfer rate in a 7200 rpm, 2MB cache HDD is 10 - 12 MB in my experiences.

Without writing to a file, I created a large enough buffer (around 384 MB), then perform the same operation (400 times with 640x480x16 region). I got 914 fps, 33 times faster than the former test. The transfer rate is: ~535 MB/sec

These tests are not precise I know, however, you can allocate a buffer first then manipulate on that buffer, it's probably better than torturing your HDD[grin].

By the way, did you try AnimGet I mentioned ?

Quote:

Original post by EnselicJust out of curiousity, what kind of application are you writing?

Quote:

Well its about recording activities of the Screen. Original post by Skeleton_V@T As I said, the processing speed depends mostly on I/O operations. Let's just do some calculations: I captured a 640x480x16 region and wrote them to a file with a loop of 400 times, the result is 27 fps. The amount of transfered data is: 640 (px) * 480 (px) * 2 (bytes) * 400 (times) ~ 234 MB There were roughly 234MB had been transfered and wrote to a file in (400 / 27) = 15 secs. So, the transfer rate is: 15.6 MB/sec. ---> You may try copying a large file to somewhere in the same hard drive, this speed is not easy to archive, the normal transfer rate in a 7200 rpm, 2MB cache HDD is 10 - 12 MB in my experiences. Without writing to a file, I created a large enough buffer (around 384 MB), then perform the same operation (400 times with 640x480x16 region). I got 914 fps, 33 times faster than the former test. The transfer rate is: ~535 MB/sec These tests are not precise I know, however, you can allocate a buffer first then manipulate on that buffer, it's probably better than torturing your HDD[grin]. By the way, did you try AnimGet I mentioned ?

Well if I can access the Screen Buffer why would I need the temporary Buffers ... I know I/O Operations are slow but wat abt block copy .. I think they are pretty fast ... Just give me a help about accessing the Screen Buffer under WinxP OS, I shall be very thankful to u :P

You can't access the screen buffer directly under Windows without writing your own device driver.

I'm not 100% sure, but I'm quite certain that the visible "buffer" that you see, resides in video-memory, thus it can't be accessed directly (need a DMA transfer to local memory).
Blt IS the fastest way to get the screen.
Blt IS hardware accelerated via your graphics adapter (at least on WinXP), thus I seriously doubt that you could make a faster version using asm.
To give you any answer that makes sense, it's important to know what you're trying to achieve?
If you're simply trying to grab a screen shot directly to the HD without doing any compression, then I guess the tests performed by others in this thread shows you where the limits are.
If you're going to compress the data to a video stream or image, there might be some more options.
I.e blt the DC to a DirectX surface, use GPU to perform color space conversions, scaling and quantizations.
Then DMA to local memory, compress data and finally save (or transmit over a network).
I'm quite sure that it wouldn't be to hard to be able to grab 1024x768 at 30+ fps.
I think that DirectShow has the ability to grab the desktop "buffer" as well.