   Windows Screen Buffer
  I want to save to capture screen shot of windows at any time. The normal screen shot is very slow. Can I access Windows Screen/Frame(waetver it is called) Buffer and copy its content to another Buffer. I guess if its possible copying block data from the address where the screen buffer first index will be... Is it possible ... somehow I want to achieve a fast Screen Capture ... Any help ???   
  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 callGetDC(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 MBThere 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/secThese 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@TAs 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 MBThere 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/secThese 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