[Bug 6936] eMule uses 40% CPU when idle permanently, independent of CPU speed

http://bugs.winehq.org/show_bug.cgi?id=6936

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #22 from Anastasius Focht   2007-11-27 09:50:22 ---
Hello,

well I took a quick glance on this.
The idle user interface update messages (WM_IDLEUPDATECMDUI) which happen to be
in quick succession are the problem.

When the app message pumping thread is idle (message queue empty), WM_KICKIDLE
is usually sent to check if idle work can be done.
If no one bothers, WM_IDLEUPDATECMDUI is sent to main window and all child
frame windows.
It walks the window tree by series of GetTopWindow() and GetWindow( xxx,
GW_HWNDNEXT) which call into wine server -> get_window_tree().

Because of tree structure a single top level WM_IDLEUPDATECMDUI causes several
GetTopWindow/GetWindow calls leading to considerable amount of CPU load
(because wine server is called each time).

When you open the options dialog, it basically sits in modal dialog loop which
is handled a bit different (WM_ENTERIDLE messages are dispatched to owner
indicating that child waits for messages).
WM_IDLEUPDATECMDUI (with its "costly" processing) is not dispatched in this
case, leading to much less CPU load.

Regards