Printable View
I know i have a long thread on this flickering topic and am not trying to drag it here but have a separate question altogether, or rather looking for reasons rather than solutions... Edit controls are created using CreateWindowEx(..., "edit",...); And this is done in WM_CREATE, so i find it strange that they would flicker because InvalidateRect() doesn't affect WM_CREATE, only WM_PAINT... Any ideas..?
When the edit controls are redrawn too fast, they flicker. This applies to all controls and text and text drawings.
I'm not redrawing the edit controls as i have mentioned that they are created in WM_CREATE... That's about the only place they appear in the code, unless windows does re-drawing somewhere by default.. Or i'm missing some info on how objects are drawn on windowsQuote:
Originally Posted by Elysia
You have to consider whether or not children are being clipped in the parent - how/when the parent paints - and other factors.
If you post a small flickering example, we can probably tell you why and how to fix it.
gg
But WM_CREATE and WM_PAINT are two different things.Quote:
Originally Posted by csonx_p
Painting is applied to all controls and regions that needs to be repainted.
They need to be repainted when some pixel inside its client area has the wrong color. Say you move a window over your edit, and then move it out. On that pixel, it would now have the color of the dialog you moved over, so the edit needs to be repainted.
And if you do this too much, it will flicker.
And when you do invalidate, you must take into account whether it will clip or repaint the child windows, as well. Windows is a complex beast, unfortunately, so I don't know exactly when and how it occurs.
Quote:
Originally Posted by Codeplug
I have a single window, what do you mean by child? And the flickering is happening without me resizing/dragging the window... Just by calling InvalidateRect()...Quote:
And when you do invalidate, you must take into account whether it will clip or repaint the child windows, as well
Can someone explaining further on the parent clipping the child anyway! These terms sounds easy for someone who has worked on Win Programming long enough...thanx
As we told you...
Each window typically has a parent. So to that parent, your window is a child window.
Every control you add to your window is also a window, thus they are children on your actualy dialog/window.
So when you invalidate, it may cause your windows children to also be invalidated and need repainting.
So the word 'window' doesn't necessary mean the normal rectangle with minimize/close/restore and title bar... Or dialog boxes. It may be a button/edit control/Static Control... But then you right cause all these are created with CreateWindow()... My stupidity there...Quote:
Originally Posted by Elysia
Just an update... I've commented every single code which draws something to the memory DC. I then called bitblt () to paint on screen an empty DC so the output would just be the edit controls (no rectangles & text)... The edit controls still flickers meaning just repainting with with bitblt causes the flickering because the moment i comment out bitblt, no flickering occurs. Am very close to giving up but something tells me it';s a small thing....
How about i rephrase my problem, perhaps may bring some light
I have a single window which i draw 5 rectangles with lots of text. 4 of these rectangles have at least each 2 edit controls for user input. The fifth rectangle is to display results calculated from the edited controls. I use the timer to update the window that whenever the user enters new data on edit controls, the results are immediately calculated.
Problem: Well, the initial compilation of the program produced terrible window flickering (could see a huge flickering from bottom up) but managed to remove that by setting wcx.hbrBackground to NULL when creating the window and also returning non-zero to WM_ERASEBKGND... The flickering is now happening on the edit controls only, not the entire window. And after a minute or so, the text display start loosing the font i used (non-bold & italics), every text suddenly becomes bold and no-italics. The borders of the rectangle also become thiner, noticed i also loose one rectangle...Also, if i leave this for a little longer, the window itself repaints badly and looses the title bar (or fades the entire blue bar), Infact, my entire screen fades some icons on the windows Start Menu bar if i let this run forever... To close my application i would have to do CNTRL+ALT+DEL. To me this seems more like memory issues (overloading buffers or something). As i said, i display a lot of text (declared as TCHAR) using TextOut() function and use CreateFont() to set my text fonts. If i comment out all my displaying of text leaving only the rectangles & edit controls to paint, i still do get flickering but not the changing of fonts and borders, and the title bar stays for longer.
All of this is after i have attempted doing the off-screen DC with bitblt... Am really stuck as to what the problem may be... Here's some of the code. It's a larger program so can't post everything here!
Code:
case WM_CREATE:
{
GetClientRect(hwnd, &clientRECT);
// Client area width & height
cScreenX=GetSystemMetrics(SM_CXSCREEN);
cScreenY=GetSystemMetrics(SM_CYSCREEN);
// Client Device Context
hDC=GetDC(hwnd);
memDC = CreateCompatibleDC(hDC);
// Memory Device Context
hBitmap = CreateCompatibleBitmap(hDC,cScreenX,cScreenY);
hOldBitmap = SelectObject(memDC,hBitmap);
// Paint screen background on mem DC grey
hBrush = CreateSolidBrush( RGB(0xD3, 0xD3, 0xD3) );
FillRect(memDC, &clientRECT, hBrush);
DeleteObject(hBrush);
ReleaseDC(hwnd,hDC);
/* Screen refresh time */
SetTimer(hwnd, IDT_REFRESH, REFRESHTIME, NULL);
/* Create edit controls */
EditBoxes(hwnd, cs);
/* Create radio buttons */
RadioButtons(hwnd, cs);
}
return 0;
case WM_PAINT:
{
hdc = BeginPaint(hwnd, &pntS);
BitBlt(hdc, 0, 0, cScreenX, cScreenY, memDC, 0, 0, SRCCOPY);
EndPaint(hwnd, &pntS);
}
return 0;
case WM_TIMER:
{
/* Begin rendering Data on Mem DC */
// Displaying text
PrintText(hwnd, rdrTrans_recv[FREQ], initRecArea(395,45,0,0), hdc,
fntClr[1].boldStyle, fntClr[0].bkgrngColor[0], fntClr[0].txtColor, fntClr[1].italicStyle);
// Retrieve data, calculate & display
output = ProcessData(hwnd);
DisplayResults(hwnd, memDC, &output, rsltFont);
InvalidateRect (hwnd, NULL, FALSE);
UpdateWindow(hwnd);
}
break;
// PrintText function
// Display text on screen
void PrintText(HWND hWnd, TCHAR txt[], RECT rc, HDC hDC, DWORD fnWeight,
COLORREF bkgrndClr, COLORREF txtColor, BOOL italics)
{
long lfHeight=-MulDiv(12, GetDeviceCaps(hDC, LOGPIXELSY), 72);
HFONT font=CreateFont(lfHeight, 0, 0, 0, fnWeight, italics,
0, 0, 0, 0, 0, 0, 0, _T("Times New Roman"));
HGDIOBJ hDefFont=SelectObject(hDC, font);
SetBkColor(hDC, bkgrndClr);
SetTextColor(hDC, txtColor);
TextOut(hDC, rc.left, rc.top, txt,(int)_tcslen(txt));
SelectObject(hDC, hDefFont);
DeleteObject(hDefFont);
}
As you may noticed, this code attempts to use Memory DC
>> The flickering is now happening on the edit controls only,
Create the parent with WS_CLIPCHILDREN - that may help.
Sounds like you've got more issues to deal with than just flickering :) ....
>> DeleteObject(hDefFont);
There's one of em. You want to delete "font" there.
gg
Wow! Solved my memory leakage problem... Font is now stable... How do i pay the bill!:)Quote:
Originally Posted by Codeplug
InvalidateRect (hwnd, NULL, FALSE) is probably responsible for the flickering. Try to remove it and see what happens. If it's no good put it back, but remove UpdateWindow(hwnd).
And how do i repaint?Quote:
Originally Posted by idelovski
The way you call InvalidateRect will make it pretty useless because it will invalidate the ENITRE client are, including your other controls, forcing them to update, as well.
InvalideRect puts the specified area into the invalidated region which is repainted the next time a WM_PAINT message is received by the program. Windows checks periodically if the invalidate queue is empty and if not, posts a WM_PAINT message. Messages that are posted is queued in the message queue, waiting there until the program handles it.
UpdateWindow on the other hand, forces the window to repaint by sending a WM_PAINT message and blocking until it is processed. It does not queue it, so likely it will incur a performance hit.
Good question!Quote:
And how do i repaint?
Now I see that you're not doing much in WM_PAINT. Only background blitting?
Then, use five InvalidateRect() calls for each edit control, but not for entire window. I don't think I have a single case of InvalidateRect() with a NULL param in my entire application because I always invalidate just small parts of the interface than really need repaint.
I have about 16 edit controls and i must have 5x16 InvalidateRect() calls...! Is this what you mean...? Oh! i don't need to update the edit controls at all in any case..., i guess doing something called 'clipping' may help but still doing some reading on it! Not sure how it's done yetQuote:
Originally Posted by idelovski
I triedQuote:
I don't think I have a single case of InvalidateRect() with a NULL param in my entire application because I always invalidate just small parts of the interface than really need repaint.
where rec was initialized by GetClientRect function... But doesn't seem to update the client window if i do thisCode:InvalidateRect (hwnd, &rec, FALSE);
Are those coordinates relative to the window's client area or the actual control's client area?
(Hint: if the top and left are 0, then it's the control's.)
Because InvalidateRect takes coordinates relative to the window whose handle you pass. So if you pass it for your window, then you must pass coordinates where your controls are located inside the dialog.
If you just want to update specific controls, you can just call invalidate and pass the handle for those controls.
Clipping regions was the solution to avoid flickering, together with double buffering.. wow! What a learning experience... Thanx Elysia for being patient with me. You form Big part of what i've learnt this past few weeks, not to forget Mats and, of cause every else who contributed. I like learning and the only way i have in the past is to ask... I guess some people don have patience with me but you guys have...Quote:
Originally Posted by Elysia
Well, talk to you when i have a new interesting problem
FYI...
Only invalidates clipped regions instead of InvalidatedRect...Code:InvalidateRgn (hwnd, rgnRsl, FALSE);
First, had to select all five rectangles into memory DC by using CreateRectRgn..
then only repainted the last rectangle (the results one) ... Nice exercise:)Code:// Create clipping regions for all five rectangles
rgnRdrAnt = CreateRectRgn(aptRect[0].x, aptRect[0].y, aptRect[1].x, aptRect[1].y);
rgnTrnRcv = CreateRectRgn(aptRect[2].x, aptRect[2].y, aptRect[3].x, aptRect[3].y);
rgnTrgt = CreateRectRgn(aptRect[4].x, aptRect[4].y, aptRect[5].x, aptRect[5].y);
rgnGenPar = CreateRectRgn(aptRect[6].x, aptRect[6].y, aptRect[7].x, aptRect[7].y);
rgnRsl = CreateRectRgn(aptRect[8].x, aptRect[8].y, aptRect[9].x, aptRect[9].y);
// .. then combine them into a single rectange
CombineRgn(cmbndRngs, rgnRdrAnt, rgnTrnRcv, RGN_OR);
CombineRgn(cmbndRngs, rgnTrgt, cmbndRngs, RGN_OR);
CombineRgn(cmbndRngs, rgnGenPar, cmbndRngs, RGN_OR);
CombineRgn(cmbndRngs, rgnRsl, cmbndRngs, RGN_OR);
// lastly, add to off-screen buffer
SelectClipRgn(memDC, cmbndRngs);
Hi,
I think I wasn't quite clear in my previous posts. I've seen your line "I have a single window which i draw 5 rectangles with lots of text." and I somehow translated that into 5 edit boxes.
That is why I said you need to call InvalidateRect() five times.
Sorry. Now I think you only need to call it once, and only for that rectangle that displays results.
Did you try processing WM_ERASEBKGND msgs (just return non zero)?
This stops alot of the flicker. As it prevents continual redrawing of the edits.
As the WM_PAINT handler does not use the update region in the BitBlt() (the paint handler redraws the entire area anyway) there will be no change adding the Rect to the InvalidateRect() call.Quote:
Originally Posted by Elysia
You would also have to use the update Rect from the PAINTSTRUCT in the BitBlt() call (ie only draw the invalidated rect, not the entire BMP in the paint.
BitBlt(hdc, pntS.left, pntS.top, pntS.right-pntS.left ,pntS.bottom-pntS.top ,msmDC ,pntS.left ,pntS.top ,SCRCOPY);
My understanding is different. InvalidateRect() generates the WM_PAINT msg.Quote:
Originally Posted by Elysia
WM_PAINT msgs are low priority (as with WM_TIMER) in the OS queue. Paint msgs are concatinated within the queue, and droped to the bottom if higher priority msgs are present.
UpdateWindow() causes the WM_PAINT msg to be posted to the app queue, not the OS queue. It is not a blocking msg like SendMesage() which must be processed before the call can complete or times out (default at 5 seconds).Quote:
Originally Posted by Elysia
Usually it is a perfomance increase not hit.
Not according to MSDN:
Quote:
Originally Posted by novacain
In other words, it does not send WM_PAINT--the system does when it thinks the time is right.Quote:
Originally Posted by MSDN
Quote:
UpdateWindow() causes the WM_PAINT msg to be posted to the app queue, not the OS queue. It is not a blocking msg like SendMesage() which must be processed before the call can complete or times out (default at 5 seconds).
Usually it is a perfomance increase not hit.
In other words, it's sent directly and not posted.Quote:
Originally Posted by MSDN
UpdateWindow() should not be needed when you don't have a timer with timeout as 1 millisecond. :D