saving the processor

[Joseph_R_Thomas]

hi, below is my on draw...
it works fine as below...

void CEditorView::OnDraw(CDC* dc)
{
	CMemDC pDC(dc);
	OnPrepareDC(pDC);
    	CEditorDoc* pDoc = GetDocument();
    	ASSERT_VALID(pDoc);
    	// TODO: add draw code for native data here - use pDC 
     	//as the device context to draw to
	
	//
	//Set the mapping mode to LOENGLISH
	//
	pDC->SetMapMode(MM_LOENGLISH);

	//
	//Convert arguments to coordinates to MM_LOENGLISH units.
	//
	CSize szTemp;
	szTemp.cx = pDoc->GetGridX();
	szTemp.cy = pDoc->GetGridY();
	pDC->DPtoLP(&szTemp);


	//
	// then draw the grid lines
	//
	CRect clipBoxRect;
	pDC->GetClipBox(&clipBoxRect);
	for(int x = 10 ; x <= pDoc->GetGridX() ; x += 10) {
		pDC->MoveTo(x, -10);
		pDC->LineTo(x, -pDoc->GetGridY());
	}
	
	for(int y = -10 ; y >= -pDoc->GetGridY() ; y -=10) {
		pDC->MoveTo(10, y);
		pDC->LineTo(pDoc->GetGridX(), y);
	}
}

it works perfectly fine as below....
now the problem is i wanan add this to my above code

	//
	//Draw the squares
	//
	/*for(int i = 0 ; i < 500 ; i ++) {
		for(int j = 0 ; j < 750 ; j ++) {
			COLORREF color = pDoc->GetSquareColor(i, j);
			CBrush brush(color);
			int x1 = (j * 10) + 10;
			int y1 = (i * -10) - 10;
			int x2 = x1 + 10;
			int y2 = y1 - 10;
			CRect rect(x1, y1, x2, y2);
			pDC->FillRect(rect, &brush);
		}
	}*/

when i do this...
all the processing power of the processor is eaten up by the processor....
can someone pls tell me a solution by which i can incorporate the above code to my View's OnDraw such that i can still retain my processing power????
tks a lot...

[Marc from D]

Do you really need to draw 375000 rectangles each time, the window is being drawn?
The game-programmers solve problems like that by doing the calculation in the graphics-board.
But it might be OK for you to set a flag in your OnDraw-function. In a timer-function you could then always draw a part of your rectangle-field. As far I can read the code, you are just painting a color-palette? You might find working examples in here in codeguru or in codeproject.

Good luck!

Marc

[Joseph_R_Thomas]

Originally posted by Marc from D
Do you really need to draw 375000 rectangles each time, the window is being drawn?
The game-programmers solve problems like that by doing the calculation in the graphics-board.
But it might be OK for you to set a flag in your OnDraw-function. In a timer-function you could then always draw a part of your rectangle-field. As far I can read the code, you are just painting a color-palette? You might find working examples in here in codeguru or in codeproject.

Good luck!

Marc

well what i am trying to do is to keep a grid in the view...its a big grid....
any solutions how i can do it????

also wat do you mean by doin calculations in the graphics board??

also what do u mean by
it might be OK for you to set a flag in your OnDraw-function. In a timer-function you could then always draw a part of your rectangle-field.
dont understand???

tks for your help...

[Marc from D]

To be honest, I do not have the smallest glue how to do calculations in the graphics board. But if you take a look at modern 3d-games: They draw thousands of polygons twenty times a second. This is done mainly using the graphics-processor, not using the cpu. DirectX might be the trick behind that. Others will be able to tell you more about that.

The other hint:
OnDraw is called each time windows invalidates your window. So this is under circumstances you do not really control and it might be very often. What you do in the moment ist to redraw everything. This is OK if you draw only a few things. But you draw a lot. My idea was now to just set a flag in your OnDraw. In a different function, i. e. a timer-based one, you can then draw the rectangles in a less consumpting way: Just each time the timer function is called ony a part of the rects is being drawn. When finished, the timer still runs, but the flag is reset and so the function does nothing.

Disadvantage: The display is drawn much slower.
Advantage: It's up to you to control the amount of drawing / cpu-consumption.

Again: I'm sure that there are better solutions, but this might be a hint for you.

Marc

[Mathew Joy]

Disclaimer: not familiar with MFC...
Why are you declaring CBrush inside the loop? Brush is a GDI object... and if it is not released after you are with it, it'll slow your app, since you are using up the resource. If the OS is w2k take Task Manager and see the no of GDI objects that you are using when your OnDraw is called. If the resource is not freed (which the constructor does) after each iteration then you can see the no of GDI objects shooting up.

If you are trying to draw a grid it is better to use lines rather than rect.

[ovidiucucu]

Originally posted by Mathew Joy
Disclaimer: not familiar with MFC...

Just note before becoming more familiar:
1. The GDI resource is deleted in CGdiObject destructor and CBrush is derived from CGdiObject;
2. CBrush brush(color) - the brush object is defined inside the loop, so it is destroyed after each iteration;

[Mathew Joy]

Originally posted by ovidiucucu
Just note before becoming more familiar:

have no intention to become...

1. The GDI resource is deleted in CGdiObject destructor and CBrush is derived from CGdiObject;

Sorry...I meant destructor when I said constructor(slip of the tongue or rather mind )

2. CBrush brush(color) - the brush object is defined inside the loop, so it is destroyed after each iteration;

Ok..just wasn't sure if it is released inside the loop itself. Still...creating and deleting a resource inside a big loop like that is not at all good. That can be declared outside the loop.

Personally, I am against declaring a variable inside the loop, since it only makes the code compiler depended and problematic.

[EDIT] (to Joseph...)
It is beter to use lines and FloodFill() than the method you are using

[bytz]

Originally posted by Mathew Joy
Personally, I am against declaring a variable inside the loop, since it only makes the code compiler depended and problematic.

[EDIT] (to Joseph...)
It is beter to use lines and FloodFill() than the method you are using

I think that variable declarations in a loop/block are a langauge feature and should not be compiler dependant, i.e. C++ allows variables to be declared on a local scope and if this causes problems with a compiler, it's not compliant with C++ standards.

I don't think that a flood fill will work if the color of the squares are changing i.e. blue, red, green, green, red, etc. some possiblities: 1) If the grid is static, i.e. the color reamians the same and a piece is drawn on it, you can create a bitmap in the program initialization, draw the grid to it, and then on the paint, just draw the bitmap before drawing the pieces. 2) You could create the brushes you need before the loop, thus saving the brush construction and destruction; 3) Get the clip region and draw only the rects that interstect with it. 4) DirectX... 5) If the board is like a chess board, fill with one color and just draw/fill the other. 6) Obviously, these suggestions can be combined.

You could post an example of what you want the board to look like and that may help with other suggestions...

[ovidiucucu]

2) You could create the brushes you need before the loop, thus saving the brush construction and destruction;

What can we do if Joseph wants to use 16,777,216 colors? Just -ing....

1) If the grid is static, i.e. the color reamians the same and a piece is drawn on it, you can create a bitmap in the program initialization, draw the grid to it, and then on the paint, just draw the bitmap before drawing the pieces.

I think this is not faster than drawing the poor grid lines...

3) Get the clip region and draw only the rects that interstect with it.

THIS IS THE POINT! A 500x750 grid is big enough to presume that Joseph tries
to draw even outside of the client area.

Anyhow, Joseph, you can take a look here...
http://www.codeguru.com/controls/gridctrl.shtml
and pick a lot of ideas.

EDITED:
---------

Originally posted by Mathew Joy
have no intention to become...

Your choice.... Just keep out of MFC discussions.

Originally posted by Mathew Joy
Personally, I am against declaring a variable inside the loop, since it only makes the code compiler depended and problematic.

Who said that? Kernighan, Ritchie, or Stroustrup?
I think none of them.

[bytz]

quote:

What can we do if Joseph wants to use 16,777,216 colors? Just -ing....

Well there is that, but I'm assuming that it's somewhat like a normal game board...

quote:
I think this is not faster than drawing the poor grid lines...

No it's faster. You generate the background borad once and only once, and then you use it (the generated bitmap) to blit in the draw. Also doing the inital drawing into a memory dc may be slightly faster, but still a one time shot. This approach offers alot of flexability, depending, of course, on how the game is set up and run...

quote:
THIS IS THE POINT! A 500x750 grid is big enough to presume that Joseph tries to draw even outside of the client area.

Presumably, yes. But also the clip region can be much smaller than the client area.... (Good point as well, Joseph shouldn't be drawing stuff that's not being displayed)

Note: these were suggestions rather than solutions.

[ovidiucucu]

But also the clip region can be much smaller than the client area....

...or null...
I have used the word even.
No problem, peace!

[bytz]

If the clip region is NULL, what's it doing being invalidated!?!?!

Not to worry, just want to make sure that good ideas (well maybe not so good ) weren't lost in the cross fire.

Peace

[Joseph_R_Thomas]

i tink i shoud go deeper into what i am trying to achieve...
i want to draw a grid..max size :640*480..
the colors being used are 3 : red, green, yellow.
thats all i have to do...
now
i have facing two problems...
1)
i have a problem in invalidating...
below is my code

void CEditorView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint) 
{
	if( lHint == 1 ) {
		//get back the rect
		CRect* pRect = ( CRect* ) pHint;
		InvalidateRect(pRect);		
		return;
	}
	CView::OnUpdate(pSender, lHint, pHint);
}

which are taken from the OnUpdate handler of my View..
the way OnUpdate is called from my DOC is as below :

void CEditorDoc::SetSquareColor(int i, int j, COLORREF color)
{
	ASSERT( i >= 0 && i <= GetGridY() && j >= 0 && j <= GetGridX() );
	m_clrGrid.At(i, j) = color;
	SetModifiedFlag(TRUE);
	CRect pRect( 20, -10, 30, -20 );
	UpdateAllViews( NULL, 1, ( CObject* )&pRect);
}

THE PROBLEM
the problem arrives when i do InvalidateRect, the rect passed in as parameter is not getting invalidated!!
i am passing the correct parameters too...
i have aready changed the color of the underlying square...after which i call the onupdate...
so by right it should change color right????
but it doesnt...
however, when i minimize and maximize the window the color has changed!!!!!!!
can u pls tell me whats wrong??

[Joseph_R_Thomas]

2)the below code is eating my the processor...

     //
     //Draw the squares
     //
     for(int i = 0 ; i < 500 ; i ++) {
          for(int j = 0 ; j < 750 ; j ++) {
               COLORREF color = pDoc->GetSquareColor(i, j);
               CBrush brush(color);
               int x1 = (j * 10) + 10;
               int y1 = (i * -10) - 10;
               int x2 = x1 + 10;
               int y2 = y1 - 10;
               CRect rect(x1, y1, x2, y2);
               pDC->FillRect(rect, &brush);
          }
     }

can i achieve the same thing with something else???
tks a lot..

[Mathew Joy]

Hi Joseph,
I guess you are working with the code that you posted in the thread 'Invalidating rect'. And I guess what you want to do is to to create or edit your bitmaps. And you want to draw a grid of lines around that bitmap, right? If so why are you iterating the loop to the no of pixels times??? You should be iterating only the no of squares...since the no. of squares is the no of pixels/10 you need to iterate only that many times.

Since I'm not an MFC programmer (I use APIs) I cannot comment (can only guess) on your problem with invalidating.

Now...you should note a few thing when you are writing a big, tight loop like that.

1. Try to avoid create and destroy resources.

I put that above the loop and saw marked improvement in the performance. You can always create the required brushes before hand if the required colors are less(In your case this is sufficient).

2. Try to avoid calling function.

As you know there is always an overhead of invoking functions. That is why macros and inline functions are there. In your case you can store the value in a variable rather than using pDoc->GetGridY().

3. Try to avoid declaring variables.

If the compiler doesn't optimize it by moving out of the loop, you are just creating/deleing the variable to/from stack. In the days of C storage class 'register' was there to move the variables (which are of-course constantly accessed, like in loops) from RAM to the processor's memory, well depening on how busy and the prority of the work being done.

Why not use floodfill()? Since you are filling the squares with solid color floodfill (beter func is extfloodfill()[check in MSDN]) will do. So you can do even if you require to choose from many colors.