http://bugs.winehq.org/show_bug.cgi?id=6936
--- Comment #30 from jm(a)jm10.no-ip.com 2007-12-06 16:21:10 ---
(In reply to comment #29)
You're right: this piece of code exists in eMule 0.48a (emuleDlg.cpp).
But if you look at comment #21, you'll that I did the tests with this version
of eMule (0.48a).
In other words, since you suggest to close this bug, do you mean eMule can't do
better ? That I will always have to keep a dialog box open ?
For me, wasting 15% of a P3 1GHz for nothing is not negligible, even if it's
less than with previous versions.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=201
--- Comment #30 from Alex Villacís Lasso <a_villacis(a)palosanto.com> 2007-12-06 15:45:49 ---
Created an attachment (id=9528)
--> (http://bugs.winehq.org/attachment.cgi?id=9528)
GetSystemPaletteEntries should fill with default palette in non-palette video
mode (with tests)
Re-diff of a pair of patches by Alexander Dorofeyev.
This was posted on wine-patches back in October. This version is rediffed
against current GIT (0.9.50). Posted here so it does not fall through the
cracks again.
The patch sort of works (it fixes transparency in igowin), but now igowin shows
a yellow shadow instead of a black square. Still, much better than the previous
situation.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6936
leuk_he <leukhe(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |leukhe(a)gmail.com
--- Comment #29 from leuk_he <leukhe(a)gmail.com> 2007-12-06 15:41:41 ---
I think the code pasted by keith that was introduced in eMule 0.48a fixes the
high idle cpu usage in wine. Under (a old version ) Xp -> vmware -> unbuntu ->
wine -> emule morph 0.48a i did expiece 5% cpu usage. , was 70% before
I suggest to close this bug.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8101
Vincent Povirk <madewokherd(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
--- Comment #1 from Vincent Povirk <madewokherd(a)gmail.com> 2007-12-06 15:19:43 ---
The hack described in http://bugs.winehq.org/show_bug.cgi?id=3023#c3 fixes this
problem. Marking as duplicate.
*** This bug has been marked as a duplicate of bug 3023 ***
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3023
Vincent Povirk <madewokherd(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |madewokherd(a)gmail.com
--- Comment #6 from Vincent Povirk <madewokherd(a)gmail.com> 2007-12-06 15:19:06 ---
*** Bug 10543 has been marked as a duplicate of this bug. ***
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=201
Alex Villacís Lasso <a_villacis(a)palosanto.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |a_villacis(a)palosanto.com
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6936
--- Comment #28 from Keith <keith_kw_muir(a)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)
}
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=5833
Austin English <austinenglish(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
--- Comment #13 from Austin English <austinenglish(a)gmail.com> 2007-12-06 11:20:24 ---
Reported fixed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.