| |
|
|
|
|
|
Forum
Please
Log In
to post a new message or reply to an existing one. If you are not registered, please
register.
NOTE: Some forums may be read-only if you are not currently subscribed to
our technical support services.
|
Subject |
Author |
Date |
|
|
Stan Miasnikov
|
Apr 18, 2008 - 11:41 AM
|
<o:p> </o:p> <o:p> </o:p> It was reported to us by several users of our applications that use Prof-UIs library: when moving mouse over the application window the CPU usage increases dramatically (could be 75%+) and sometimes the desktop flashes (like if you call invalidate rect on the desktop window). <o:p> </o:p> We have done several tests and have found out that this behavior is not unique to just this application but any other we’ve built with this library. Furthermore, this behavior can be reproduced with ProfStudio sample without any modifications. <o:p> </o:p> This is a very serious problem, which, unless resolved, will force us to drop using this library. <o:p> </o:p> To reproduce: compile ProfStuio sample and run it. Open task manager and monitor CPU usage. Move cursor over the ProfStudio application window and just move the mouse around while the cursor is within the application window limits. Observer CPU usage may go up to 100% and sometimes remains high even after you stop moving the cursor. In some instances, you may see that the entire desktop is invalidated. <o:p> </o:p> Please advise ASAP.
|
|
|
Technical Support
|
Apr 22, 2008 - 7:44 AM
|
We have analyzed the CPU usage issue. It heavily depends on the number of windows created inside the main frame window. The number of windows in the ProfStudio sample is far greater than it is in any application from our customers we have ever seen. Each of bars receives command updating request. So, the CPU usage is high but not 100% on a 2GHz single CPU computer. You can decrease CPU usage by closing bars in the ProfStudio sample application. The CPU usage in real projects will much more depend on the implementation of each command updating handler method rather than on the number of windows. Your command updating methods should not be heavy. They should return the execution control as earliest as possible. They should not invoke COM, OLE, inter process communication, database and other APIs which may post messages to the thread’s message queue or execute for a long time. The screen flicker was not noticed in our test. We can review your project if you send it to us.
|
|
|
Stan Miasnikov
|
Apr 22, 2008 - 12:30 PM
|
Well, then, as I suspected, the problem is that you call <o:p></o:p>
CExtToolControlBar::OnUpdateCmdUI(CFrameWnd* pTarget, BOOL bDisableIfNoHndler)<o:p></o:p>
on each Mouse move (actually hit test most likely) event for each control bar when the mouse is hovering over the main window, not just specific control bar. I see that this method is calling pTBB->OnUpdateCmdUI for each button<o:p></o:p>
you need to filter UpdateCmdUI calls, so it is not called so often.<o:p></o:p>
while command update handling for each button, at leas in our case, is quick, but due to the large number of buttons still uses lot’s of CPU.<o:p></o:p>
Besides, I never noticed standard MFC application exhibiting similar behavior. We used the stingray library before for number of years, and I don’t remember running into such problem.<o:p></o:p>
|
|
|
tera t
|
Apr 21, 2008 - 7:19 PM
|
Other sample MDI.exe does not seem to use a microprocessor power so much.
When application uses many CExtControlBar, such a symptom seems to come out ....
|
|
|
Slim Ghariani
|
Apr 18, 2008 - 2:56 PM
|
We’re having the same problem, and posted about it 3 days ago but no valid answer yet...
|
|