In reference to Windows GDI, what is the difference between an invalid and valid region? I understand that a call to InvalidateRect() sends a WM_PAINT message to the queue, but what exactly is an "invalid" region?
I understand that a call to InvalidateRect() sends a WM_PAINT message to the queue.
Well, not exactly. When you call InvalidateRect, you mark that rectangular region as being invalid and needing to be repainted. But no messages are sent. In fact, no message is even posted to the queue.
When you call GetMessage, or one of its equivalents, if the queue is empty, and there are windows in the thread that have dirty regions, then the system synthesises a WM_PAINT message. This synthesised WM_PAINT message is returned from GetMessage. The window's handler for WM_PAINT should then paint the window and thus make it valid again.
So, an invalid region is one that is pending painting. You have told the system that you want that region to be re-painted, and the system will arrange for that to happen once the higher priority queued messages have been processed.
The windowing system generally tries to avoid redrawing anything unless necessary, e.g. because something has changed, or another window has moved across it. When this happens, it marks the region as invalid to say that it needs to be redrawn. Alternatively, a region/window can be manually invalidated to force a redraw.
When the application responds to the WM_PAINT message, it will try to be as efficient as possible by only redrawing in the invalidated area. When it's finished, it marks it as valid to indicate that it's now up-to-date.
This selective redraw approach isn't as important today as it used to be. In the past, the drawing operations were much slower, so optimisation was absolutely essential.
Related
I have a fairly simple windows program that created a listview control that should exactly fill the client area. That works at start up, and I think will work if the window is resized --- except the windows NEVER receives any WM_SIZE messages (after the initial one sent on window creation.) I verified this using Spy++x64 as an administrator to ensure I was capturing everything. Spy++ showed the window receiving WM_SIZING, WM_WINPOSCHANGED, WM_NCCALCSIZE, and WM_WINPOSCHANGING (this list isn't in any particular order) but NEVER a WM_SIZE.
This is a 64-bit program, but I don't know why that should matter.
So, is there something I could have done that allows the window to be completely resizable, but prevent Windows from ever generating WM_SIZE messages when that happens? If not, is there something I need to do (that was never needed in the past 30 years) to let Windows know I need to see those WM_SIZE events?
It turns out that the default window procedure generates the WM_SIZE when it processed WM_WINDOWPOSCHANGED and, since I was handling WM_WINDOWPOSCHANGED, no size messages were created. So I forwarded the position changed message to the default handler and the messages are back.
This follows documented behavior. There's a remark in the documentation for the WM_WINDOWPOSCHANGED documentation:
By default, the DefWindowProc function sends the WM_SIZE and WM_MOVE messages to the window. The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc. It is more efficient to perform any move or size change processing during the WM_WINDOWPOSCHANGED message without calling DefWindowProc.
Yup, I'm sorry to admit that I failed to read the documentation for all of the Window messages that I was NOT having problems with when I needed to find out about WM_SIZE. Silly me for not assuming the documentation I needed about WM_SIZE was only to be found under some other message! All it says about the message generation in the WM_SIZE documentation is:
Sent to a window after its size has changed.
There is no mention AT ALL of any dependency on the default processing for a DIFFERENT message to be found. Ergo, the behavior is effectively undocumented, especially since it may be critical information, as it was for me.
Oh well, I give up, this place has become far too much of just smacking people down for asking questions some people think are too easily answered. Try to remember that not everyone has an eidetic memory and access to all of the documentation you have all memorized. Some of us look up the thing we're working on and expect to find the important details about it. THEY ARE NOT PRESENT. Bye!
I'm dealing a lot with drawing. Currently I'm using WM_TIMER to schedule painting using InvalidateRect. For some reason WM_PAINT is then very often called with region (0,0,0,0), so basically an empty rectangle. I tried to interpret this as "the whole window", but then it seemed to cause quite some performance decrease. Why is Windows sending it then?
Your question is quite well answered in the standard documentation: http://msdn.microsoft.com/en-us/library/windows/desktop/dd145213%28v=vs.85%29.aspx.
Basically, the system sends WM_PAINT messages when the message queue is empty and by default it does so on occasion regardless of whether there is anything to paint or not. Many older applications depended on WM_PAINT (for example to do idle time processing) and keeping this behaviour ensures compatibility.
No, you must not assume it means the whole screen. If the region is empty you should avoid calling BeginPaint/EndPaint and just pass it through to the default window procedure.
ShowWindow(g_hWnd, 1);
UpdateWindow(g_hWnd);
I am wondering why we need to call UpdateWindow following the ShowWindow?
It is entirely unnecessary, your window will paint just fine without it.
You'll see a minor benefit from it if your program goes off doing lots of stuff after creating the window but before entering the message loop. The user has something to look at. A splash screen is the more typical approach.
ShowWindow does not repaint the window. The call to UpdateWindow sends WM_PAINT message to the window and thus repainting it.
Normally, the system sends WM_PAINT only if the message queue is empty. Under normal circumstances this is good enough and it actually optimizes out a lot of unnecessary repaint. The messages in the queue often will change application state which can often result in invalidating part of the window, and hence result in yet another painting (so the user sees the new application state). So the repaint just happens after all such messages are handled and the system thinks the new window content will be valid for some time (until yet another message(s) come into the queue).
However if you need to force the WM_PAINT immediately and bypass the logic above, you may force sending WM_PAINT (if there is an invalid region) by calling UpdateWindow().
ShowWindow causes a WM_PAINT message, whereas anything which makes a previously hidden part of a window visible. UpdateWindow does any outstanding paint message(s) to be delivered immediately, waiting until the paint processing is complete until returning. Without the call to UpdateWindow the message isn't received until your program goes into the message loop. This avoids any possible delay in response to the user.
We have a MFC Visual-C++ application that is not reacting to any user input.
(Note: Currently only known on one machine. The behavior does recur occasionally, but only after the App has been running for several days!)
The application is redrawn when we switch to it via Alt-Tab (or the Task Bar), but we cannot, for example, activate it's main window by clicking on the title bar.
We have already pulled 4 dumps with WinDbg and checked the active instructions. We always were in some redraw code or somesuch inside the main thread (the GUI thread). We definitely were/are not in a modal message loop and the main thread's stack always looked "OK". (Most/all worker threads were idling, waiting for some event, no suspicious code there either.)
When investigating the problem with Spy++, we see the behavior specified also in this separate question, namely that we seem to get paint and activation messages, but no user input is routed to the application. When I have the application window on the screen, and select it to show messages of the main window,
it will only show "generic" "referesh" messages and nothing else
If I drill deeper, and select all messages for the whole process,
this is what we see:
The app is apparently only processing messages on one hidden sub-window (00CB09F0), and what we see there is a constant stream of 200 WM_PAINT messages per second.
Normally this Sub Window isn't processing any messages at all (except refresh WM_PAINT etc. when Windows sends them). It is normally used as a drawing area and the drawing happens through a WM_TIMER message on it's parent (010A09B8) window. (This WM_TIMER message isn't shown on the hanging app either though.)
The performance profile as shown in process explorer looks like this (100% kernel time, more or less):
I'd say that you have a redraw loop in that window that receives the WM_PAINT flood.
That usually happens if you call Invalidate or similar from the processing of the WM_PAINT message, directly or indirectly.
Other posibility is that, since you say that you are using a timer to redraw the window, the actual drawing is taking more time that the time it self, so the messages pile up in the queue.
Yet another posibility is that you are invalidating the window from a different thread than the one making the painting.
Anyway, you should ensure that you are calling Invalidate*() properly (you showed no code), and never from the OnPaint event. And avoid calling UpdateWindow() as this function can mess things if called without a little care.
I've seen this problem when an exception is thrown from a dialog. MFC's DoModal function disables the main program window then reenables it when the dialog returns; exceptions bypass the reenabling part and the main window remains disabled forever.
I've got a few layered windows in my app that use UpdateLayeredWindow() to handle their visual representation. According to the MSDN article on layered windows, "when using UpdateLayeredWindow() the application doesn't need to respond to WM_PAINT or other painting messages." They shared some of the same message handlers as non-layered windows, so I figured I would just return early from WM_PAINT handling if the target is a layered window.
Of course, this caused one major issue: if one of the layered windows did get a WM_PAINT message, the input queue would end up flooded with an unending stream of WM_PAINT messages. This end-result makes sense, since the window would never be validated and so it will keep thinking it needs to paint (I shouldn't be returning from the handler without validating or BeginPaint()ing, etc.), but what doesn't make sense is why it received the message in the first place, since it has no effect on a window that was using UpdateLayeredWindow().
It wouldn't even happen reliably -- just every now and then, and not every time the window's pixels needed redrawing. Sanity was restored by falling back to DefWindowProc() when a layered window got a WM_PAINT message, but I feel like something is going on that I don't understand. And considering how seldom this problem manifested itself, I'm worried this might just be hiding an even subtler problem. Is it expected behavior for a window using UpdateLayeredWindow() to still get the occasional WM_PAINT message? Does it matter, as long as I handle it correctly?
Additional info, if needed: the window is calling UpdateLayeredWindow() immediately after being created, and then it's left on its own (it doesn't call it again, since it doesn't change). Using C++ and win32 API, no MFC.
I had run into similar issues before, although my memory may be a bit rusty by now.
First off, keep the DefWindowProc. When the docs say you don't have to respond, I would take that to mean to ignore the message entirely, rather than prevent default handling.
I personally experienced this from two different causes. One was a window which was actually sending WM_PAINT messages (evil! beware!). The other (IIRC) resulted from certain RedrawWindow calls. In both cases, I chalked the problem up to poorly written code, outside of my control, and never had any situations arise from simply passing it down to DefWindowProc.
Hopefully you will have the same experience!
Good luck. I found layered windows to be poorly documented and full of interesting caveats and gotchas, but very pleasing once you get all the kinks worked out.