saving the processor

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

Code:

---

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

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...

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

Quote:

---

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??:confused: :( :confused:

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???:( :confused: :(

tks for your help...

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

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.

Quote:

---

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;

Quote:

---

Originally posted by ovidiucucu
Just note before becoming more familiar: ;)

---

have no intention to become...;) ;)

Quote:

---

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 ;) )

Quote:

---

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

Quote:

---

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...

Quote:

---

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 :D-ing....

Quote:

---

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...

Quote:

---

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:
---------

Quote:

---

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

---

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

Quote:

---

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. :D

Quote:

---

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:

---

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:

---

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.

Quote:

---

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

---

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

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

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

Peace :D

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

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 :

Code:

---

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??

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

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);
          }
    }

---

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

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.

Several things:

[CODE]
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);
}
[\CODE]

Will not work as the pRect vzariable is local will probably go out of scope if UpdateAllViews is posting messages...

In your square drawing code (besides thte advice that Mathew gave you) you're continually recalculating the x & y's for the rect. You should move the y calculation to the outer loop as it will be the same for each j:

[CODE]
//
//Draw the squares
//
CRect rect;

rect.top = -10;
rect.bottom = -20;

for(int i = 0 ; i < 500 ; i ++)
{
rect.left = 10;
rect.right = 20;

for(int j = 0 ; j < 750 ; j ++)
{
COLORREF color = pDoc->GetSquareColor(i, j);
pDC->FillSolidRect(rect, color);

rect.left += 10;
rect.right += 10;
}

rect.top -= 10;
rect.bottom -= 20;
}
[\CODE]
Note: I did not compile this code!!!

This should help with some of the speed problems. Another optimization would be to get the clip region and only draw the rects that are contained inside of the clip regions bounding rect.

Quote:

---

Originally posted by bytz
Another optimization would be to get the clip region and only draw the rects that are contained inside of the clip regions bounding rect.

---

this is what am trying to do since day one....:(:(
but i have no clue whatsoever....
i posted many questions but no one could help..:(
can u help me ad tell ho wcan i use the GetClipRect in my scenario please??????
tks a lot...really appreciate your help....

Quote:

---

Originally posted by bytz
In your square drawing code (besides thte advice that Mathew gave you) you're continually recalculating the x & y's for the rect. You should move the y calculation to the outer loop as it will be the same for each j:

[CODE]
//
//Draw the squares
//
CRect rect;

rect.top = -10;
rect.bottom = -20;

for(int i = 0 ; i < 500 ; i ++)
{
rect.left = 10;
rect.right = 20;

for(int j = 0 ; j < 750 ; j ++)
{
COLORREF color = pDoc->GetSquareColor(i, j);
pDC->FillSolidRect(rect, color);

rect.left += 10;
rect.right += 10;
}

rect.top -= 10;
rect.bottom -= 20;
}
[\CODE]
Note: I did not compile this code!!!

---

i didnt understand the above..i duno how to take it off my codes....:(:(
if i use the above codes..where should i fill the rect??:(:confused:
this is what i have done till now...

Code:

---

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

---

but i still face the same probs......:(
pls help.....
aslo can u pls tell mw how can i use the clip rect method...
tks a lot..
really appreciate your help...

Quote:

---

Originally posted by Mathew Joy
Hi Joseph,
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.

---

hi. i am iteraing the number of pixels cause i have to draw the four corners of rectangle....if am wrong..pls tell me how can i do it the way you are suggesting....
above you can see the code that i have changed according to what you said..
if you want pls take a look at my proj that is attached below...tks a lot....
really appreciate your help...

Quote:

---

Originally posted by Joseph_R_Thomas
hi. i am iteraing the number of pixels cause i have to draw the four corners of rectangle....if am wrong..pls tell me how can i do it the way you are suggesting....
above you can see the code that i have changed according to what you said..
if you want pls take a look at my proj that is attached below...tks a lot....
really appreciate your help...

---

In your project you are supposed to display(create) a bitmap of the height h (say) and width w, as specified in the dialoge box that appears when the project starts. Next you should tell which method u've chosen. Either way (using brushes or floodfill), you are trying to fill squares right? And if you not are choosing from many colors both are almost same in terms of using processor power (to the eye). But I guess floodfill is better than using brushes.
The outer loop indictate the rows and the inner the cols. (or y and x) Note here I'm talking about the loop that follows

Code:

---

//draw the squares

---

. Now why are you iterating the outerloop the y times (or rather nGridY) and the inner x times? You are not doing something with each pixel are you? so it should be the no of square times. Since the size of the square is 10 pixels you should iterate nGridY/10 times and nGridX/10 times.

And let me tell you...if you want to optimize that loop the first thing you should do is to take the

Code:

---

CBrush brush(color);

---

out of the loop. And also make sure that you are not drawing anything outside the client window(and not much even if you are). As others suggested in this thread you should clip the region to your client window.

Guess this helps

And when you are dealing with points in graphics, test to see if they are correct. (You can use SetPixel() for instance)

Quote:

---

Originally posted by Mathew Joy
But I guess floodfill is better than using brushes.

---

can u pl tell me how can i replace my code with floodfill please????

Quote:

---

Originally posted by Mathew Joy

And let me tell you...if you want to optimize that loop the first thing you should do is to take the

Code:

---

CBrush brush(color);

---

out of the loop

---

i canot take it out...cause if i take it out i cannot draw the brush...:(
if i put this outside the code
CBrush brush
then inside the loop it doesnt allow me to do this
brush(color)
so i am using it inside...any way ai can do the above so tat i can move
CBrush brush
to out of the loop???:confused:
this is what i have done till now with your kind help..

Code:

---

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

---

Quote:

---

Originally posted by Mathew Joy
As others suggested in this thread you should clip the region to your client window.

---

i have no idea how to applu the getclip to my proj...i asked many questions byut noone could help...can u pls help me on GetClipRect??
tks a lot...really appreciate your time and help..

First about the question of taking the brush out of the loop, it is not difficult...provided the no of colors that you use is relatively small. Say in your case you have 3 colors...so create 3 brushes before hand. If the color is red, use the corresponding brush...similarly with green and blue.

Now about the question of flood fill, take a look at MSDN...if you don't have better download or get it from someone. Look at the func ExtFloodFill(). You can fill it 2 ways either by specifying the boundary of the squares, if it is constant, or by specifying the color of the surface to be filled. You should note that the x,y that you specify must be a point inside the square. Since the grid must be present before flood filling you must draw grid before.

About the clip region I recomend you to use MFC since you are using that...I may not be able to help because I use APIs rather the classes.

Now I want to tell something about your question...your actual need and your question are way different...that's why those suggestions weren't of help to you. Since all are not in a position to download your code and check it, make sure that your question reflect your actual need. I still don't have a first hand idea of what you are trying to accomplish(you didn't answer to many of my questions regaring your project). So do all who answered in this thread

ok...tks ...i will answer your qeustions here...
i am trying to make a graphic editor...
the grids are supposed to be the enlarged squares..
and the top view is supposed to be the preview window....
as the squares are filled in the lower half of the app the upper half will be filled correspodingly..
what i am thinking is
1 square in the lower half = 1 pixel in the upper half of the app..

total nomber of colors to be used are 3
total number of squares to be used are 6400x4800...
above is what the app is all about...
its a very simple app...
i have 2 views in it...the bottom view(with the squares)is caled the EditorView
the top view(the preview area) is called the PeekView..
now i have having a lot of probs in drawings...:(
cant seem to get it working...
tin the attached version o f the proj...i tried to activate the PeekView...and now the whole things doesnt work!!:(:(i am getting link errors...
i hope you can pls help me..tks a lot for your time...really appreciate it..

regarding the ExtFloodFill...
it says i need to to specify x and y...
but what i have is a rect.....:(
how can i put the rect in the ExtFloodFill..????
is there a way???
tks a lot..

Code:

---

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

---

regarding the above code...as you see the point where i get the color is inside the loop!!!
so if thats the case, how can i declare the brush outside and chage its color fro within the loop???:confused: :confused:

Try the following piece of code:

Code:

---

        //
        //Draw the squares
        //
        int nGridX = pDoc->GetGridX();
        int nGridY = pDoc->GetGridY();
        COLORREF color;
        int x1;
        int y1;
        y1 = -10;
        for(int i = 0 ; i < nGridY ; ++i) {
                y1 -= 10;
                x1 = 0;
                for(int j = 0 ; j < nGridX; ++j) {
                        color = pDoc->GetSquareColor(i, j);
                        x1 += 10;
                        dc->FillSolidRect(x1,y1,10,10,color);
                }
        }

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

---

OK, let's try to put an end to this drama. A few notes:

• First of all, don't even think about using FloodFill. FloodFill is a function to fill an arbitrary shaped region. It uses a recursive algorithm which scans the DC line by line, and is highly inefficient compared to FillRect(). So stay with FillRect() for filling rectangles.
• To get your updating and drawing to work, first remove the CMemDC stuff, as it obscures what is really happening. Without the offscreen drawing, you will see much better what is going on. Furthermore, you will note that you don't need offscreen drawing in order to remove flicker for your application.
• Next, remove your implementation of OnEraseBkgnd (or call the base class implementation). You will definitely need to erase the background.
• Now to your updating problem: Note that UpdateRect() expects the rect in device coordinates, you are passing logical coordinates. So create a CClientDC, set the mapping mode to MM_LOENGLISH and use LPToDP to convert the rect to device coords (the same way you did in OnLButtonDown).
• Next, fix the bugs in CEditorDoc::SetSquareColor(). You are always returning the same rect, build it from x1, y1, x2, y2 instead. Note that you also have i and j swapped.
• If you compile and run your app now, you will note that it works fine (albeit slow): Any field you click will be repainted without any flicker. However, it takes some time, as you are creating and deleting the brush and calling FillRect() for every field. Now let's go about optimizing:
• Take into account the clipping region when drawing the rectangles. The easiest way to do it is to call pDC->IsRectVisible(). So inside your loop, for every rectangle you get, test whether it is actually visible (meaning: it is inside the clipping region) and create the brush and call FillRect() only if this is the case. You will now note that your app runs fine as before, only much faster. (To speed things further up, you should also draw the grid lines only if they fall into the clipping region).
• Although this will probably already fit your needs, a more intelligent (read: efficient) way of optimizing the drawing will be to get the bounding rectangle of the visible region and determine which fields fall into that region. Then you could set the start and end values of your two nested loops to those values.
• Just a last hint: The code to convert from a given square(i,j) to its actual coordinates (and back) is replicated in several places of your code. You should probably wrap that into two methods (e.g. GetSquareBounds / GetSquareFromPoint). This will be especially helpful if you want to change the square size and offset from 10 to something else in the future.

Quote:

---

Originally posted by gstercken
FloodFill is a function to fill an arbitrary shaped region. It uses a recursive algorithm which scans the DC line by line, and is highly inefficient compared to FillRect(). So stay with FillRect() for filling rectangles.

---

You are right if FloodFill uses recursive algs...but I doubt since if filling a large area, the stack could easily run out. There are non-recursive floodfill alg available but writing a recursive floodfill is easy. I would appreciate if you could post or point to any material that confirms it.

Quote:

---

Originally posted by Mathew Joy
You are right if FloodFill uses recursive algs...but I doubt since if filling a large area, the stack could easily run out. There are non-recursive floodfill alg available but writing a recursive floodfill is easy. I would appreciate if you could post or point to any material that confirms it.

---

The point is not whether the actual implementation of the Win32 ExtFloodFill() is recursive or not - any recursive algortihm can be rewritten without recursion. The point is that FloodFill (recursive or not) is extremely slow when compared to FillRect, so replacing FillRect by FloodFill is counter-productive as an optimizing measure.

See my post above. The version I posted runs pretty fast!

Instead of floodfill or fillrect, just use FillSolidRect (like in my post). This way you don't even have to create a brush!

Also put most of the calculations outside the loop and get rid of the multiplications, not that they are that slow but they can easily be replaced with addition (see my post).

Quote:

---

Originally posted by Marc G
Instead of floodfill or fillrect, just use FillSolidRect (like in my post). This way you don't even have to create a brush!

Also put most of the calculations outside the loop and get rid of the multiplications, not that they are that slow but they can easily be replaced with addition (see my post).

---

Yes, using FillSolidRect() and avoiding the multiplications are further optimizations. But the code still needlessly calls GetSquareColor() and FillSolidRect() for all the squares outside the clipping region - this should clearly be avoided. Also note that FillSolidRect() has the side effect of changing the DC's current background color (it uses ExtTextOut to fill the rect).

How would you get rid of the GetSquareColor() call? In each iteration we need to retrieve the color for that rectangle. Every rectangle can have a different color, so, I think GetSquareColor() is required. Am I wrong?

Like I said, the version I posted above is really fast even without taking clipping region into account.

Quote:

---

Originally posted by Marc G
How would you get rid of the GetSquareColor() call? In each iteration we need to retrieve the color for that rectangle. Every rectangle can have a different color, so, I think GetSquareColor() is required. Am I wrong?

---

Look at my post above. If you check for RectVisible() inside the loop, you can avoid the superfluous calls for GetSquareColor().

Oops, sorry, didn't read your post correctly the first time...
You said "GetSquareColor is needlessly called for rectangles outside the clipping region" and i stopped after the "called" so I read "GetSquareColor is needlessly called" :o

Quote:

---

Originally posted by Marc G
See my post above. The version I posted runs pretty fast!

Instead of floodfill or fillrect, just use FillSolidRect (like in my post). This way you don't even have to create a brush!

Also put most of the calculations outside the loop and get rid of the multiplications, not that they are that slow but they can easily be replaced with addition (see my post).

---

the code above desnt do anything when i put in in my project...:(

You should not expect really working code here. Just take the hints and try to pick the ones that you think are best.

And now I'm going back to my hints at the start of the thread: You should think about various things: Do you really need to draw so many rects? You should only draw the visible things! I would personally now spend more time in thinking about those things than in coding the fastest draw-routine.
Think about different concepts: As you are drawing that much, is it really what the user wants / needs? Are other ways to display your data better?
Have you tried to fill the whole area with one of your three colors and then only drawing the others?

I think you got many, many good hints until now. It is now up to you to try out how good they really are. This is work to do. Nobody else but you will do this.

I started software-developing 1.5 years ago. I learned a lot from codeguru. Almost always when I had a question, I got a good answer. But the biggest advance came from doing it. Just taking working code without understanding what other brains produced led me always into the dark. My pc crashed often as I did things wrong, but with ongoing training I'm getting better each day.

So my best hint: Just try to understand what the others told you already. Think about the hints, pick the best ones and then try to change your code by yourself. Nobody else will write the code for you.

I really think that the best help the community can give you on a long term is to stop this discussion now. If you have a new question regarding a special command, search the forum for it.

Good luck!

Marc

That code I posted does work.
Try the following OnDraw function:

PHP Code:

---

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
    
    CRect rcClient;
    GetClientRect(&rcClient);

    dc->FillSolidRect(0,0,rcClient.Width(), rcClient.Height(), RGB(255,255,255));

    //
    //Set the mapping mode to LOENGLISH
    //
    dc->SetMapMode(MM_LOENGLISH);

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


    //
    //Draw the squares
    //
    int nGridX = pDoc->GetGridX();
    int nGridY = pDoc->GetGridY();
    COLORREF color;
    int x1;
    int y1;
    y1 = -10;
    for(int i = 0 ; i < nGridY ; ++i) {
        y1 -= 10;
        x1 = 0;
        for(int j = 0 ; j < nGridX; ++j) {
            color = pDoc->GetSquareColor(i, j);
            x1 += 10;
            dc->FillSolidRect(x1,y1,10,10,color);
        }
    }

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


---

Also, remove your OnEraseBkgnd handler, it's not needed.

Then, in your OnLButtonDown you'll need to add an Invalidate() call inside your if(...) to redraw the grid.

Also, I don't know what you exactly want. When you launch your editor it asks two numbers. When I enter 100 and 50 does this mean there should be 100x50 little squares??

Joe, have a look at my post above. It tells you in detail where the bugs are in your code and what you have to do to get it working.

tks a lot for your post Mr.'G'....really appreciate your help and time...

Quote:

---

First of all, don't even think about using FloodFill. FloodFill is a function to fill an arbitrary shaped region. It uses a recursive algorithm which scans the DC line by line, and is highly inefficient compared to FillRect(). So stay with FillRect() for filling rectangles.

---

ok...i will..:)

Quote:

---

To get your updating and drawing to work, first remove the CMemDC stuff, as it obscures what is really happening. Without the offscreen drawing, you will see much better what is going on. Furthermore, you will note that you don't need offscreen drawing in order to remove flicker for your application.

---

done...looking forward to see that and learn:)

Quote:

---

Next, remove your implementation of OnEraseBkgnd (or call the base class implementation). You will definitely need to erase the background.

---

done..

Quote:

---

Now to your updating problem: Note that UpdateRect() expects the rect in device coordinates, you are passing logical coordinates. So create a CClientDC, set the mapping mode to MM_LOENGLISH and use LPToDP to convert the rect to device coords (the same way you did in OnLButtonDown).

---

i already did that...:(
its in my OnUpdate handler....:confused:

Quote:

---

Next, fix the bugs in CEditorDoc::SetSquareColor(). You are always returning the same rect, build it from x1, y1, x2, y2 instead. Note that you also have i and j swapped.

---

done the SetSquare part...but the swapping issue...i THINK its ok now...??:confused:

Quote:

---

If you compile and run your app now, you will note that it works fine (albeit slow): Any field you click will be repainted without any flicker.

---

it doesn't....:(
onluy some fields can be painted... rest canti dont understand whats happening...:(
some fields cant be painted....:eek:

Quote:

---

Take into account the clipping region when drawing the rectangles. The easiest way to do it is to call pDC->IsRectVisible(). So inside your loop, for every rectangle you get, test whether it is actually visible (meaning: it is inside the clipping region) and create the brush and call FillRect() only if this is the case. You will now note that your app runs fine as before, only much faster. (To speed things further up, you should also draw the grid lines only if they fall into the clipping region).

---

i have no idea hopw to do this..i know maybe its something regarding getClipRect..i read MSDN..but i have no idea how to use it in my codes....:(please help....

attached is the current version of the proj..
but it cant scroll when using big sizes like when i enter
640 and 480 in the dlg that apprears before the app starts...

this is the current proj...i ahve done some changes in a try to make the scrolling acceptable..i have not succeeded but atleast i have done something....please take a look, cause i havent been able to solve the problem yet...and only some squares can be drawn...others cant...i have used the code by Mr.Mark G too...but still only a part of the squares can be drawn..rest cant...:(

ideas?:( :confused:

hi guys....
tks a lot for helping...
with Mr.G. Stercken and Mr.Marc G's help i have done this much in the proj..
attached is the project...
i can draw now..
but there are slight problems..
1)when i draw, somethings blinking..:(can i get rid of it?
2)currently normal pixels used are 100 and 50...i.e 100 small squares are drawn across and 50 squares are drawn below...but, If i change it to 680 and 480..my grid becomes endles...:()
moreover..i can't scroll properly..:(
if you can pls help...
tks a lot...really appreciate your help...thank you.

Try the following OnDraw code:
NOTE: The code below is not the prettiest code, but I'm sure you get the idea.

Code:

---

void CEditorView::OnDraw(CDC* pDC)
{
        CEditorDoc* pDoc = GetDocument();
        ASSERT_VALID(pDoc);
   
    CRect rcClient;
    GetClientRect(&rcClient);
    pDC->FillSolidRect(0,0,rcClient.Width(), rcClient.Height(), RGB(255,255,255));

    //
    //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);

        int iHScroll = GetScrollPos(SB_HORZ);
        int iVScroll = GetScrollPos(SB_VERT);
        CSize scroll(iHScroll, iVScroll);
        // NOTE: I don't know if this is necessary
        pDC->DPtoLP(&scroll);

    int nGridX = pDoc->GetGridX();
    int nGridY = pDoc->GetGridY();

        // Calulcate visible region
        int yStart = scroll.cy / 10;
        int yEnd = yStart + rcClient.Height() / 10;
        int xStart = scroll.cx / 10;
        int xEnd = xStart + rcClient.Width() / 10;
        if (yStart < 0) yStart = 0;
        if (yEnd > nGridY) yEnd = nGridY;
        if (xStart < 0) xStart = 0;
        if (xEnd > nGridX) xEnd = nGridX;


    //
    //Draw the squares
    //
    COLORREF color;
    int x1;
    int y1;
    y1 = -10*(yStart+1);
        for(int i = yStart ; i < yEnd; ++i) {
        y1 -= 10;
        x1 = 10*xStart;
        for(int j = xStart ; j < xEnd; ++j) {
                        color = pDoc->GetSquareColor(i, j);
                        x1 += 10;
                        pDC->FillSolidRect(x1,y1,10,10,color);
        }
    }

    //
    // then draw the grid lines surrounding them
    //
    CRect clipBoxRect;
    pDC->GetClipBox(&clipBoxRect);
        int x = 10*xStart;
    for(int i = xStart; i <= xEnd ; ++i) {
                x += 10;
        pDC->MoveTo(x, -(yStart+1)*10);
        pDC->LineTo(x, -(yEnd+1)*10);
    }
    int y = -10 * yStart;
    for(int i = yStart; i <= yEnd; ++i) {
                y-=10;
        pDC->MoveTo((xStart+1)*10, y);
        pDC->LineTo((xEnd+1)*10, y);
    }
}

---

Also in your OnInitialUpdate use something like:

Code:

---

SetScrollSizes(MM_LOENGLISH, CSize(pDoc->GetGridX()*10 + 100, pDoc->GetGridY()*10 + 100));

---

to calculate scrollbar sizes.

Then add a WM_VSCROLL and WM_HSCROLL handler and put

Code:

---

Invalidate(FALSE);

---

in it.

The code above works rather fast even when you enter something like 6400x4800 at startup of the program, but when you do, startup of the program itself is a bit slow because of memory allocation and stuff. But once it has started it works fast.
NOTE: There's still a bug when using big sizes like 6400x4800: the scrollbars start to overflow because the range is too big.

Quote:

---

Originally posted by Marc G
NOTE: There's still a bug when using big sizes like 6400x4800: the scrollbars start to overflow because the range is too big.

---

the max size gonna be entered is 640 x 480 only..

Quote:

---

Originally posted by Marc G
The code above works rather fast even when you enter something like 6400x4800 at startup of the program, but when you do, startup of the program itself is a bit slow because of memory allocation and stuff. But once it has started it works fast.
NOTE: There's still a bug when using big sizes like 6400x4800: the scrollbars start to overflow because the range is too big.

---

i did what all you wrote/....but the app became slower ibnstead of faster...what i mean is that when i scroll after adding your the Invalidate(FALSE) and adding the scrolPos in OnDraw...the scroll has become slower...actually it doesnt allow me top scroll...and shows a blank screen when i pres sthe scroll once..:(:confused:

When i get back home, i'll send you my project files.

hi...i got your proj....tks a lot for your help and effort..
but the display always shows EMPTY SPACE between the right scroll bar and the grid even when i am in the center of the grid...:(
and space between the bottom scroll bar and the grdi even when i am in the middle of the screen....:(
also i cant draw on the last bottom line of the grid...:(:confused::eek:

thisis what i have come up iwth,.,,,but now i got FLASHING problem...........pls help...:(

To solve the white space you got:

Code:

---

    CRect rcClient;
    GetClientRect(&rcClient);
    // Add the following 2 lines after you've set the mapping mode to MM_LOENGLISH
    pDC->DPtoLP(&rcClient);
    rcClient.bottom *= -1;

---

If you've got everything working then you can try to remove the flickering with a memory DC.

Create a memory DC, do all your drawing in this mem dc and blit the final result to the screen.

If you do this, do not forget to add a handler for WM_ERASEBKGND and just return TRUE.