|
I've created a custom control, using the low level win32 api, which displays an animation. Using a thread I render a frame, or rather update the parts need it, and call InvalidateRect passing the area that was changed. In the main thread I handle WM_PAINT with the BeginPaint EndPaint pair AND use the paintstruct's rect to repaint only the area required.
The rendering is backed by a TimerQueue, an event and a thread that waits on the event.
I couldn't work out why my CPU usage was hovering around 80%. Each frame involves a lot of alpha blending hence the need to only update the changed parts.
After 2 days I've narrowed the problem to BeginPaint. MSDN states, and this is GDI 101, when handling a WM_PAINT message BeginPaint and EndPaint should be called to validate the invalid rect, otherwise windows will continue to post the message.
Well, it's just not happening. The window has not been validated and my code has been rendering the full client area (lot's of work) on each call. If I add a ValidateRect in my handler the problem goes away and CPU down to 0-1%.
My question is why? Is this a bug or am I missing something?
Waldermort
|
|
|
|
|
WalderMort wrote: a ValidateRect in my handler the problem goes away
I think that's the correct way.
Don't know if it's a bug or not.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
|
Hmpf! I stand corrected. I was going off of faint memory. Like I said, "I thought".
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
Well, if the documentation says you have to do it and the experimentation shows that you have to do it, seems like it's working as designed. Not a bug, the rules.
|
|
|
|
|
Chuck O'Toole wrote: Well, if the documentation says you have to do it and the experimentation shows that you have to do it, seems like it's working as designed. Not a bug, the rules.
But the documentation doesn't say that, infact it says that since I am calling BeginPaint there is no need to call ValidateRect. http://msdn.microsoft.com/en-us/library/dd145194(VS.85).aspx[^]
Waldermort
|
|
|
|
|
Well, you don't show how you do the re-drawing of the area in your WM_PAINT processing. Where did you place the call to ValidateRect()? Immediately on entry or just before the EndPaint()? Is it possible that you are calling some other functions that cause the invalidate to happen (explicitly or implicitly) before the call to ValidateRect()?
|
|
|
|
|
It's too much code to simply paste here. You'll have to take my word for it that there is no way for the rect to be invalidated other than when I explicitly call for it.
My code works like this. bitmap A is updated from a thread. Thread calls InvalidateRect when done updating a frame. bitmap B contains the window background and doesn't change. bitmap C is a double buffer. When WM_PAINT arrives, call BeginPaint, alpha blend bitmap A with B onto C and BitBlt bitmap C to the screen. When done call EndPaint.
Like I said this is GDI 101, and I have never had a problem like this with previous versions of windows or Visual Studio.
As it stands now, calling ValidateRect from anywhere in the WM_PAINT handler solves the problem. I currently have it after the call to EndPaint. Without this call, WM_PAINT is being sent from window creation and always with the full client area. Even though at that time my drawing routines have not yet begun. And yes I do call Begin End on EVERY WM_PAINT.
On another note, passing the message onto DefWindowProc, after those two calls, also results in undesired behaviour. rectangles are being validated but not those that are in the paint struct.
I'm really beginning to think this is a bug.
Waldermort
|
|
|
|
|
Of course, if this were a newly introduced bug in Windows (not saying that it isn't) then we'd expect to see a lot more programs going into high cpu usage processing WM_PAINT messages.
Theory goes that the EndPaint() call will take care of the ValidateRect() on the .rcPaint member of the PAINTSTRUCT you received in BeginPaint(). Is that the same thing you are using in your manual ValidateRect() call? Is there a possibility that it is being clobbered during your paint processing? If .rcPaint changed between Begin and End that would explain what you see. You say you use that member to do your re-drawing, read-only?
|
|
|
|
|
Chuck O'Toole wrote: Theory goes that the EndPaint() call will take care of the ValidateRect() on the .rcPaint member of the PAINTSTRUCT you received in BeginPaint(). Is that the same thing you are using in your manual ValidateRect() call? Is there a possibility that it is being clobbered during your paint processing? If .rcPaint changed between Begin and End that would explain what you see. You say you use that member to do your re-drawing, read-only?
BeginPaint() actually.
Like you said though, if it were a bug... which makes me think there must be a problem in my code somewhere.
Anyway, found it! Deep in there was a legacy debug routine to update the entire screen. Now to find out who made it and then...
Thanks for the suggestions though.
Waldermort
|
|
|
|
|
Hi Friends,
My software server listens on a particular port using dedicated "listener thread" . We accept the connections from client and serve this request on different threads.
Under high input requests from client (12000 approx/sec), the "listener thread" dies. Any suggestion for this kind of problem?
Currently it looks to me that the select or accept call is possibly the reason behind. Should we use pselect or simialr to this?
~ Vikram S
|
|
|
|
|
vikrams wrote: the "listener thread" dies.
Please clarify "dies." Is there an error?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Well, the first place I would look for is running out of memory. Depending on how you create the thread (_beginthreadex / CWinThread class / whatever) if you are creating a thread for each of the 12000/second arrivals, you might run out of some resource. You might check for stack size too, if I remember correctly, each thread gets a stack and that's taken off the end of your stack so, eventually, there'll be some overlap. I'm a bit foggy on that but it caused me problems in the past and I had to build the app with a larger stack size.
|
|
|
|
|
I still working on my SQL Server Scanning Program. I can enumerate all the server names on the LAN, but I need something to store the names in. I'm using a collection, because the number of names is different every time.
I can add names, edit and remove names in the collection, but I can't figure out how to populate the collection in another class, and return it back for more processing. When I try to pass the collection, I get the missing list of arguments message.
The link to the collection I made.
Creating a Collection Class in C++[^]
|
|
|
|
|
jkirkerx wrote: When I try to pass the collection, I get the missing list of arguments message.
What are you trying to pass it to?
|
|
|
|
|
I thought it was an object, that I could pass down to a function, down to another function, like a HWND object. But it was not the case, because after more research, You can't pass a template collection according to my limited reading. So I pasted my class SQL Enumerator function up 1 level, and condensed it.
I'll keep my ears open for a better way of storing values while I work with them.
|
|
|
|
|
Guys,
I have to maintain a number of legacy products which are DOS applications, developed using MSVC 1.52. I have just splashed out on a new laptop only to find that MSVC1.52 refuses to install undr Windows 7, even in XP (and Win 98) compatibility mode.
Anyone managed to do this, or does anyone know of a C compiler which will produce 16 bit DOS apps but will run under Windows 7?
The code is C and not C++ and does not us MFC.
Thanks
Tony
|
|
|
|
|
I believe XP (and before) used to have an emulator that would allow it to run 16bit applications... that's probably gone in the newer OS's... try to search for a 16bit emulator that you can run under...
|
|
|
|
|
|
Thanks,
You are right of course, the problem is not so much related to Windows 7 but to the 64 bit platform. That makes the problem all the more difficult because its not just a case of replacing the OS.
I saw that Windows 7 Pro has an XP mode but I guess it will be XP/64 so the problem will still be the same.
Things are never easy (sigh!) 
|
|
|
|
|
Have you considered simply using a virtual machine? I've got win7 (home premium, so no XP emulation mode) I simply installed Virtual Box before installing XP, linux Mint, etc inside it.
You'll have no problem installing XP, 2000 or 98 in it, and from there any version of visual studio you please. Of course there's always the MS Virtual PC, or the ubiquitous VMWare.
|
|
|
|
|
I have a 64-bit Windows 7 system, running 32 bit XP in the virtual machine, so that may be an answer. You can get the VM from Microsoft[^].
|
|
|
|
|
As pointed out by others, 64-bit Windows does not support 16-bit programs even though Intel x64 and AMD64 do support 16-bit programs.
However there is a program called DOSBox (http://www.dosbox.com/download.php?main=1[^]) that can be used to run 16-bit programs.
I use this program to run the old classic DOS games.
|
|
|
|
|
Thanks,
I saw DOSBox but I dont actually run the DOS apps on the development PC as they are embedded. The real problem is getting Microsoft Visual C++ V1.52 to install and run so I am looking for a Windows on Windows solution. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
