There's a default implementation for WM_SETREDRAW, but you might be able to do better

There’s a default implementation for WM_SETREDRAW, but you might be able to do better

Date:	January 24, 2011 / year-entry #17
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20110124-00/?p=11683
Comments:	15
Summary:	If your window doesn't have a handler for the WM_SETREDRAW message, then DefWindowProc will give you a default implementation which suppresses WM_PAINT messages for your window when redraw is disabled, and re-enables WM_PAINT (and triggers a full repaint) when redraw is re-enabled. (This is internally accomplished by making the window pseudo-invisible, but that's an implementation...

If your window doesn't have a handler for the WM_SETREDRAW message, then DefWindowProc will give you a default implementation which suppresses WM_PAINT messages for your window when redraw is disabled, and re-enables WM_PAINT (and triggers a full repaint) when redraw is re-enabled. (This is internally accomplished by making the window pseudo-invisible, but that's an implementation detail you shouldn't be concerned with.)

Although the default implementation works fine for simple controls, more complex controls can do better, and in fact they should do better, because that's sort of the point of WM_SETREDRAW.

The intended use for disabling redraw on a window is in preparation for making large numbers of changes to the window, where you don't want to waste time updating the screen after each tiny little change. For example, if you're going to add a hundred items to a list box, you probably want to disable redraw while adding the items so you don't have to suffer through 100 screen refreshes when only one is enough. You've probably seen the programs that forget to suppress redraw when filling a large list box: The application freezes up except for a list box whose scroll bar starts out with a big thumb that slowly shrinks as the number of items increases.

I say that this is sort of the point of WM_SETREDRAW for a complex control, because if you have a simple control (like a button), there isn't much in the way of "bulk updates" you can perform on it, so there isn't much reason for anybody to want to disable redraw on it anyway. The types of windows for which people want to disable redraw are the types of windows that would benefit most from a custom handler.

For example, the list view control has a custom handler for WM_SETREDRAW which sets an internal redraw has been disabled flag. Other parts of the list view control check this flag and bypass complex screen calculations if is set. For example, when you add an item to a list view while redraw is disabled, the list view control doesn't bother recalculating the new scroll bar position; it just sets an internal flag that says, "When redraw is re-enabled, don't forget to recalculate the scroll bars." If the list view is in auto-arrange, it doesn't bother rearranging the items after each insertion or deletion; it just sets an internal flag to remember to do it when redraw is re-enabled. If you have a regional list view, it doesn't bother recalculating the region; it just sets a flag. And when you finally re-enable drawing, it sees all the little Post-It note reminders that it left lying around and says, "Okay, let's deal with all this stuff that I had been putting off." That way, if you add 100 items, it doesn't perform 99 useless scroll bar calculations, 99 useless auto-arrange repositionings, and create, compute, and then destroy 99 regions. Since some of these calculations are O(n), deferring them when redraw is disabled improves the performance of inserting n items from O(n²) to O(n).

Moral of the story: If you have a control that manages a large number of sub-items, you should have a custom WM_SETREDRAW handler to make bulk updates more efficient.

Bonus chatter: Note that using LockWindowUpdate as a fake version of WM_SETREDRAW does not trigger these internal optimizations. Abusing LockWindowUpdate gets you the benefit of not repainting, but you still have to suffer through the various O(n²) calculations.

Comments (15)

Joel says:

January 24, 2011 at 7:56 am

I wish Visual Studio 2008 would use something like this for the toolbox sidebar which takes forever, as it adds each custom control one-by-one to the list while also repeatedly jumping between the topmost, bottommost and currently selected items in the list (for no apparent reason).
640k says:

January 24, 2011 at 8:05 am

If you think vs2008 is slow, try vs2010.
Joshua says:

January 24, 2011 at 8:52 am

Just don't use the designer and you'll be fine.

I almost never use it these days. I can do a smaller/faster/better job in code.
Alex Grigoriev says:

January 24, 2011 at 10:15 am

I wish Windows Live (DirectActiveX.NET just kidding) Mail programmers worked in the same company as Raymond Chen. Oops, they do. The damn thing doesn't know to use WM_SETREDRAW when deleting the mails from the list.
@Alex Grigoriev says:

January 24, 2011 at 1:26 pm

I wish the commenters would actually complain on the correct blog windowsteamblog.com/…/windowslive. Oops, that would mean they'd have to do something other than complain to someone who has nothing to do with said product. This means I have to read the damn comments that have nothing to do with the post.
Joel says:

January 24, 2011 at 2:00 pm

@Alex I'm not really planning to do anything about it. It's a minor annoyance, honestly, and only an issue the first time I start up VS for the day. Still…I wish they had used something like WM_SETREDRAW. Just sayin'.
Brian Frost says:

January 24, 2011 at 2:43 pm

I've seen the angst over the 'wrong' use of LockWindowUpdate in favour of WM_SETREDRAW but my approach to reducing screen flicker in my Delphi Apps is rather empirical. In my tools box I have four possibilities – DoubleBuffered (writes the bitmap to a backing canvas before painting), BeginUpdate-EndUpdate (ListView, TreeView etc) LockWindowUpdate() and WM_SETREDRAW. I fiddle with each until I find a solution that looks nice. Invariably LockWindowUpdate looks best although I know its naughty. Why is it best?

[It's not surprising that naughty gives the best results for the person being naughty. If your network card doesn't implement exponential backoff but instead always retransmits immediately, then you will win all collisions. If you steal from the store, you don't have to pay. If you grab all the crayons in art class, then you will have an easier time drawing your pictures. Of course, you also screw over everybody else. -Raymond]
kinokijuf says:

January 24, 2011 at 9:25 pm

@Alex Grigoriev;@Alex Grigoriev: I bet this is leftover from OE. I see exact same behaviour in winmail.
bad api says:

January 24, 2011 at 11:05 pm

[It's not surprising that naughty gives the best results for the person being naughty. If your network card doesn't implement exponential backoff but instead always retransmits immediately, then you will win all collisions. If you steal from the store, you don't have to pay. If you grab all the crayons in art class, then you will have an easier time drawing your pictures. Of course, you also screw over everybody else. -Raymond]

Exponential backoff will most likely make collisions worse. Only random backoff will minimize collisions.

To draw flicker free in windows gdi you have to STEAL resources?

[Who said you were stealing resources? I was just giving real-world examples of how bad people get an advantage over people who follow the rules. -Raymond]
Brian Frost says:

January 24, 2011 at 11:55 pm

..and my real point is why should LockWindowUpdate() give a 'better' visual effect than WM_SETREDRAW?

[I thought I explained it in the article. WM_SETREDRAW lets the control decide how to redraw. Maybe the control does a bad job. But instead of LockWindowUpdate you can just ShowWindow(SW_HIDE), which is a local solution. -Raymond]
nikos says:

January 25, 2011 at 1:45 am

talking about the listview control, its implementation of setredraw is very buggy. If I turn redraw off, then add/rearrange a lot of items, chances are that when redraw is re-enabled the control will not paint fully, not scroll correctly or both. The end result leaves much to be admired (especially in LVS_LIST) so usually I request a full redraw with Invalidate() after each WM_SETREDRAW(true)
GregM says:

January 25, 2011 at 7:46 am

Nikos, how is it buggy when it behaves exactly as documented?

This message can be useful if an application must add several items to a list box. The application can call this message with wParam set to FALSE, add the items, and then call the message again with wParam set to TRUE. Finally, the application can call RedrawWindow(hWnd, NULL, NULL, RDW_ERASE | RDW_FRAME | RDW_INVALIDATE | RDW_ALLCHILDREN) to cause the list box to be repainted.
Gabe says:

January 25, 2011 at 9:11 am

If you're trying to avoid flickering, I don't see how ShowWindow(SW_HIDE) would help. It sounds like you're suggesting that one should hide the control, perform updates, and show it again. That will definitely cause flickering!

[But it will speed up the update. If you want to get rid of the flickering, you disable redraw on the parent, I guess. Or put up a cover window. -Raymond]
bad api says:

January 25, 2011 at 10:19 am

Nikos, how is it buggy when it behaves exactly as documented?

The listview content is easily provoked to garbage when enabling gridlines and adding items.
bob asking says:

January 27, 2011 at 6:59 am

Can you please clarify about WM_SETREDRAW message – does it allow nesting? I mean if you do SendMsg(WM_SETREDRAW, FALSE) twice, then SendMsg(WM_SETREDRAW, TRUE) twice, will it allow repainting only after second SendMsg(WM_SETREDRAW, TRUE)?

Also, from your post it is not very clear to me how should I implement WM_SETREDRAW. Are there any examples of how it could be done? For example, should I call default implementation? And what other messages should be handled in specific way while setredraw flag is set?

[WM_SETREDRAW does not nest. I'll consider "How to implement WM_SETREDRAW" a topic suggestion since I'm not going to try to create a scratch program in a comment. -Raymond]

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

<-- Back to Old New Thing Archive Index