Analyzing 70.000 pixels color as fast as is possible.

[arva]

Hi, after a big research I finally found a solution to make sreenshots;p But what is bothering me - when I do some tests it shows up that analizing about 66.000 pixels takes 50-60% of my CPU resources(Intel Core Duo 1.66 GHz). Is there a faster way to do that?
Here is the code:

//---------------------------------------------------------------------------
	#include <vcl.h>
	#pragma hdrstop
	#include "Unit1.h"
	//---------------------------------------------------------------------------
	#pragma package(smart_init)
	#pragma resource "*.dfm"
	#include <windows.h>
	#include <stdio.h>
	#include <winuser.h>
	#include "fstream.h"
	 
	String dir;
	String czas;
	String data;
	int b=0;
	int s=0;
	 	 
	TForm1 *Form1;
	//---------------------------------------------------------------------------
	__fastcall TForm1::TForm1(TComponent* Owner)
	        : TForm(Owner)
	{
	}
	//---------------------------------------------------------------------------
	 
	 
	void __fastcall TForm1::Timer1Timer(TObject *Sender)
	{
	 
	b++;
	if(b>1000) return;
	 
	         TCanvas &PulpitCanvas = *new TCanvas();
	         Graphics::TBitmap *bitmap = new Graphics::TBitmap;
	         COLORREF k[116][114];
	         HWND Wnd=FindWindow(NULL,"WINDOW");
	         if(Wnd==0)
                 {MessageBox(0,"Didnt found the window!",0,0);}
	         PulpitCanvas.Handle = GetDC(Wnd);
	         bitmap->Width = 800;
	         bitmap->Height = 600;
	 
	bitmap->Canvas->CopyRect(Rect(0, 0, bitmap->Width,    bitmap->Height), &PulpitCanvas, Rect(0, 0, bitmap->Width, bitmap->Height));
	 
	for(int i=0; i<116; i++)
	{
	    for(int j=0; j<114; j++)
	    {
	       if(bitmap->Canvas->Pixels[i][j]==RGB(0,0,0));
	       if(bitmap->Canvas->Pixels[i][j]==RGB(0,0,0));
	       if(bitmap->Canvas->Pixels[i][j]==RGB(0,0,0));
	       if(bitmap->Canvas->Pixels[i][j]==RGB(0,0,0));
	       if(bitmap->Canvas->Pixels[i][j]==RGB(0,0,0));
	    }
	}
	 
	ReleaseDC(0, PulpitCanvas.Handle);
	delete &PulpitCanvas;
	delete bitmap;
	   
	 }
	 
	//---------------------------------------------------------------------------

[arva]

Sorry, for the code but there was no option to get it into the block. And I have no option to edit my post. Is it normal?

[Marc G]

you used the wrong ending code tag.
The proper syntax is: [ code ]...[ /code ] without the spaces.

[Marc G]

You say it uses 50-60% CPU.
That doesn't say anything actually.
Does it use 50-60% CPU for half a second, 1 second, 1 minute?
Are you sure you are running a RELEASE build?
If you are running a DEBUG build that might explain the low performance.

[srelu]

Professionally, pixel-by-pixel image processing is done using low level Assembler code to access directly the memory where the pixels are stored. That greatly speedes up the work. You don't have to be an Assembler guru, you only need to know how to write embedded loops, access the stack, the memory and the registers. The _asm keyword allows you to insert directly Assembler code in a C/C++ program.

You will need to rewrite several times the same algorithm, one time for each possible color deepth. The differences are caused by the fact that in a 32 bit per pixel bitmap you will have four bytes defining each pixel, in a 24 bit per pixel you will have 3 bytes defining each pixel and so on.

Also, you'll need to create your bitmap with the CreateDIBSection function.

[VladimirF]

Professionally, pixel-by-pixel image processing is done using low level Assembler code to access directly the memory where the pixels are stored. That greatly speedes up the work. You don't have to be an Assembler guru, you only need to know how to write embedded loops, access the stack, the memory and the registers. The _asm keyword allows you to insert directly Assembler code in a C/C++ program.

This is a popular misconception. Even if you are an ASM guru, you will have a very hard time competing with modern optimized compilers. And if you are not a guru – don’t even bother.
However, you do NOT need assembler to get a direct access to your pixels.

Also, you'll need to create your bitmap with the CreateDIBSection function.

The OP’s code uses Borland’s VCL library. I am not familiar with it, but guessing (based on the fact that it provides per-pixel access) that it has a DIB section.

[MrViggy]

Is the algorithm taking a long time? The fact that it uses 50-60% of your CPU really means nothing. Your Central Processing Unit is there to do one thing, process. If it's not processing (idle), you're just wasting energy.

Viggy

[VladimirF]

Hi, after a big research I finally found a solution to make sreenshots;p But what is bothering me - when I do some tests it shows up that analizing about 66.000 pixels takes 50-60% of my CPU resources(Intel Core Duo 1.66 GHz). Is there a faster way to do that?

As Marc pointed out, 50% is NOT a measure of speed, it’s CPU utilization.
For your dual-core processor, it likely means 100% utilization of one core by a single thread. In other words, your app constantly does something CPU-intensive.
What is your timer interval? May be the work in your TForm1::Timer1Timer simply can’t be completed in such interval?
Also, your code does nothing useful. It appears to copy part of the screen content into the bitmap, and then discards that bitmap.
And your nested loops do nothing at all. Five times!

As for the optimization, I suggest few things:
1. Create your bitmap once, outside of that timer handler.
2. Move FindWindow() call to the top of the function, and return immediately if not found. There is no reason to copy anything from non-existing window.
3. If that window was found, save its handle in a member variable and don’t call FindWindow() anymore.
4. Same applies to your Canvas. It could be created only once, when the window was found.

[ASHL33T]

If I may butt in with a off-topic request, could you share how you made your code take screenshots? I found some code by Napalm @ rohitlab.com but it freezes the screen for a small period of time and id like screenshotting to be much smoother, unless theres no way to escape this tiny delay.