http://bugs.winehq.org/show_bug.cgi?id=5770
--- Comment #2 from Austin English <austinenglish(a)gmail.com> 2007-11-27 11:02:47 ---
The demo works fine for me in wine 0.9.49. Can you try this in wine 0.9.49 and
report back?
--
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=6033
kujeger <kujeger(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kujeger(a)gmail.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
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |focht(a)gmx.net
--- Comment #22 from Anastasius Focht <focht(a)gmx.net> 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
--
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=5623
--- Comment #11 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2007-11-27 09:25:13 ---
wineserver already stores keyboard state for every thread. 'async' could
mean to use the state from a foreground thread. That won't work of course
if a foreground/active window doesn't belong to Wine, or belongs to a
different wineserver session.
--
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=5623
--- Comment #10 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2007-11-27 09:16:49 ---
(In reply to comment #8)
Why can't Wine share the keyboard state between it's processes? We don't need
support from X to do that. Of course we won't get all the kbd events from the
whole screen. That indeed requires extra X communication. Which btw already
available form X (like capture). Too bad XInput doesn't work for this.
--
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=4197
--- Comment #13 from Scott Russell <bugzilla(a)bluecamel.eml.cc> 2007-11-27 09:08:05 ---
I just tried 0.9.49 from the winehq deb repo. No change there. I'll download
wine-cvs and try with the patch posted. Thanks for the quick response!
--
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=5623
Dan Kegel <dank(a)kegel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dank(a)kegel.com
--- Comment #9 from Dan Kegel <dank(a)kegel.com> 2007-11-27 08:35:43 ---
If we really need X support, the 1.0 goal would be
"figure out what we really need and get it added
to X and Wine"; it's ok if people can't use it for
a while as long as we get the ball rolling.
--
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 #21 from jm(a)jm10.no-ip.com 2007-11-27 07:04:15 ---
(In reply to comment #18)
> Do you still get CPU usage issues in 0.9.49?
>
Yes. I use eMule 0.48a under Wine since version 0.9.40 and I see no improvement
in 0.9.48 and 0.9.49.
The behaviour described by comment #14 is still there so I always leave the
"Add new friend..." dialog box open. Here are stats from "top" (delay: 60s) :
0.9.48 - chat tab. + dialog box
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7768 jm 30 15 2602m 188m 6088 S 3.3 29.8 597:10.27 emule.exe
7772 jm 30 15 24488 21m 576 S 0.3 3.4 57:15.97 wineserver
7151 jm 25 10 19072 16m 1612 S 0.2 2.5 12:57.48 Xtightvnc
0.9.48 - chat tab.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7768 jm 30 15 2602m 188m 6088 R 10.9 29.8 597:23.04 emule.exe
7772 jm 30 15 24488 21m 576 S 9.4 3.4 57:26.41 wineserver
7151 jm 25 10 18628 15m 1612 S 0.1 2.5 12:57.67 Xtightvnc
0.9.49 - chat tab. + dialog box
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9134 jm 30 15 2601m 58m 9576 S 1.8 9.3 1:40.20 emule.exe
9138 jm 30 15 4356 1980 624 S 0.2 0.3 0:21.01 wineserver
7151 jm 25 10 18220 15m 2196 S 0.1 2.5 13:13.78 Xtightvnc
0.9.49 - chat tab.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9134 jm 30 15 2601m 59m 9576 S 10.2 9.4 1:51.52 emule.exe
9138 jm 30 15 4356 1980 624 S 9.3 0.3 0:30.80 wineserver
7151 jm 25 10 17776 15m 2196 S 0.1 2.5 13:13.96 Xtightvnc
(P3 1GHz, no download, uploading at 40kB/s to ~10 clients)
--
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=5623
--- Comment #8 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2007-11-27 02:14:25 ---
(In reply to comment #7)
> What if just Wine processes had a consistent view of key state? It seems that
> would be good enough for the two mentioned applications.
What do you mean by "consistent view of key state"? X server notifies
a window when keyboard mapping does change, and Wine updates its state
accordingly. X server notifies only those windows which get the focus,
i.e. not focused Wine windows have no idea about current X keyboard state.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.