Problem with custom draw flickering in MFC

  • Thread starter Thread starter Arnold the Aardvark
  • Start date Start date
A

Arnold the Aardvark

[New to MFC]

I am creating a custom draw tree view based on CTreeCtrl.
When the control is re-sized the background is blanked
completely, resulting in a horrible flicker.

I've seen various suggestions involving the use of double
buffering. Those are fine but I want to understand what is
wrong. When I created the same control in C++Builder the
view was totally flicker free, so this must be something
the framework does (or doesn't).

Now, from the good old days of plain C API programming, I
vaguely remember that you could override the default
behaviour of a window class (to blank the background with
the brush supplied in WNDCLASS). Gonna have to find my
Petzold... :-)

So my question is: how do I do this in MFC? I have spent
all afternoon fiddling with likely candidates, but the
tree view is blanked before any of them are called.

Also, how can a tell Windows to start sending all the
Custom Draw notifications from inside OnPaint()?

Thanks.


Arnold the Aardvark

'And no, C++ does not have "garbage collection".
Thank God for that. C++ gives me the ability to not
create garbage in the first place.' - Ed Mulroy
 
Arnold the Aardvark said:
[New to MFC]

I am creating a custom draw tree view based on CTreeCtrl.
When the control is re-sized the background is blanked
completely, resulting in a horrible flicker.

I've seen various suggestions involving the use of double
buffering. Those are fine but I want to understand what is
wrong. When I created the same control in C++Builder the
view was totally flicker free, so this must be something
the framework does (or doesn't).
Click to expand...

Perhaps c++ builder does double buffering by default (ie the DC you get is a
memory DC that is later put to screen).
Now, from the good old days of plain C API programming, I
vaguely remember that you could override the default
behaviour of a window class (to blank the background with
the brush supplied in WNDCLASS). Gonna have to find my
Petzold... :-)

So my question is: how do I do this in MFC? I have spent
all afternoon fiddling with likely candidates, but the
tree view is blanked before any of them are called.

Also, how can a tell Windows to start sending all the
Custom Draw notifications from inside OnPaint()?

Thanks.
Arnold the Aardvark

'And no, C++ does not have "garbage collection".
Thank God for that. C++ gives me the ability to not
create garbage in the first place.' - Ed Mulroy
Click to expand...

Lol. Wouldn't memory leaks classify under 'garbage'? ;-) They pollute don't
they? Lol

http://www.codeproject.com/gdi/flickerfree.asp
http://www.codeproject.com/gdi/flicker_free_intro.asp
 
Make sure that you: get the proper DC to draw on (should be clipped to just the
invalidated area), select a clipping region into the DC for the invalidated
area prior to drawing, or limit your drawing to just the invalidated region.

Also, there are windows flags that affect how sizing invalidations are handled
-- whether or not a size invalidates the entire client area, or just the
affected portion.
 
I sorted this out - mostly. The problem was the interaction
with the CView holding my control. I had to override the
default OnEraseBkgnd. I think the CView class might not
clip children, so when it clears (despite none of it being
visible), it wipes the tree out completely.

There is still a bit of flicker due to my own painting, but
it is much better than before. I could probably live with it.
I might look into some of the other custom draw stages...
Perhaps c++ builder does double buffering by default (ie the
DC you get is a memory DC that is later put to screen).
Click to expand...

I don't think so. However, the image in Builder is absolutely
rock solid - no detectable flicker whatsoever - so I'll have
to look a bit more deeply into what's going on. You may be
right though that seems awfully wasteful for a default
implementation.
Lol. Wouldn't memory leaks classify under 'garbage'? ;-) They pollute
don't they? Lol
Click to expand...

I think Ed's point was that it is not difficult to write C++ that
will not leak resources even in the presence of exceptions, thanks
to the RAII idiom. In any case, GC only protects memory and seems
to create more problems than solutions if you want determinisic
clean up of other resources, such as mutex locks. YMMV.
http://www.codeproject.com/gdi/flickerfree.asp
http://www.codeproject.com/gdi/flicker_free_intro.asp
Click to expand...

Thanks for these links.


Arnold the Aardvark
http://www.codeproject.com/cpp/garbage_collect.asp
 
Back
Top