http://bugs.winehq.org/show_bug.cgi?id=6936
--- Comment #28 from Keith keith_kw_muir@blueyonder.co.uk 2007-12-06 13:29:15 --- (In reply to comment #27)
(In reply to comment #26)
Hello again,
another option would be to use a newer emule version (> 0.47c). I fetched the 0.48a source code just to look at the usual MFC brain damage and it seems they improved the idle processing situation a bit (in my opinion not enough). By filtering a specific amount of WM_TIMER to prevent idle processing overkill, the generated CPU load is reduced by a few points.
If you don't want to use a newer version because you have own modded/hacked emule version, you can of course "backport" the changes. Look for CemuleApp::IsIdleMessage, only a few source lines. Though I would recommend trimming idle handling a bit more aggressively.
Lastly you could filter WM_KICKIDLE in wine by yourself and "eat" a specific amount using diff ticks to enforce a specific idle message rate. Though I wouldn't really recommend this change because its somewhat intrusive and might break other applications.
Regards
My personal experience of the Emule development team is that "we don't support linux" seems to be their entire attitude. If someone from the wine team approached them that might make a difference far more likely is to approach one of the many modders to get this work done.
this was taken from the Emule forum hope it helps
BOOL CemuleApp::IsIdleMessage(MSG *pMsg) { // This function is closely related to 'CemuleDlg::OnKickIdle'. // // * See MFC source code for 'CWnd::RunModalLoop' to see how those functions are related // to each other. // // * See MFC documentation for 'CWnd::IsIdleMessage' to see why WM_TIMER messages are // filtered here. // // Generally we want to filter WM_TIMER messages because they are triggering idle // processing (e.g. cleaning up temp. MFC maps) and because they are occuring very often // in eMule (we have a rather high frequency timer in upload queue). To save CPU load but // do not miss the chance to cleanup MFC temp. maps and other stuff, we do not use each // occuring WM_TIMER message -- that would just be overkill! However, we can not simply // filter all WM_TIMER messages. If eMule is run:qning in taskbar the only messages which // are received by main window are those WM_TIMER messages, thus those messages are the // only chance to trigger some idle processing. So, we must use at last some of those // messages because otherwise we would not do any idle processing at all in some cases. //
static DWORD s_dwLastIdleMessage; if (pMsg->message == WM_TIMER) { // Allow this WM_TIMER message to trigger idle processing only if we did not do so // since some seconds. DWORD dwNow = GetTickCount(); if (dwNow - s_dwLastIdleMessage >= SEC2MS(5)) { s_dwLastIdleMessage = dwNow; return TRUE;// Request idle processing (will send a WM_KICKIDLE) } return FALSE; // No idle processing }
if (!CWinApp::IsIdleMessage(pMsg)) return FALSE; // No idle processing
s_dwLastIdleMessage = GetTickCount(); return TRUE; // Request idle processing (will send a WM_KICKIDLE) }