Hi Thomas,
meanwhile I've analysed and worked around the issue partially.
I'll send the config later today.
It's not just unmovable windows, it's rather unbound mouse
actions.
The easiest way to reproduce the issue is a binding to a
non-exeisting Function:
Mouse 3 R C Function ThisFunctionDoesNotExist
Another easy way of reproduction is the following mouse binding
suggested in FvwmPager's man page:
Mouse 3 R C Module FvwmPager -transient
It causes again CPU load if you hold and move the mouse instead
of click - release.
Even if you bind the key sequence to a function like
Mouse 3 R M Function MapPager
DestroyFunc MapPager
AddToFunc MapPager
+ C Module FvwmPager -transient
... which *lacks* a binding for M, you run into the CPU issue.
Why does fvwm wait for something more than a mouse button down here?
There is neither a D, H or M to wait for.
A workaround is to bind M to pop up a menu with the same functionality:
+ M PopUp MenuTransientFvwmPager
DestroyMenu MenuTransientFvwmPager
AddToMenu MenuTransientFvwmPager
+ transient FvwmPager Module FvwmPager -transient
So the root cause seems to be simply an unbound function,
*and* that fvwm waits for something instead of breaking out of
the function/loop.
Sometimes it beeps (which I did not hear initially due to xset b off).
For the move / resize issue I just pop up an single line menu
like the above calling Nop, see below:
DestroyFunc FuncTestResize-or-Lower
AddToFunc FuncTest_Resize-or-Lower
+ I PipeRead `xprop -id $[w.id] \
| grep _NET_WM_ACTION_RESIZE /dev/null 2/dev/null \
echo Function Resize-or-Lower \
|| echo Function ResizeError-or-Lower`
DestroyFunc ResizeError-or-Lower
AddToFunc ResizeError-or-Lower
+ C Lower
+ M PopUp MenuResizeNotAllowed
# Notification on unmovable / unresizable windows:
DestroyMenu MenuResizeNotAllowed
AddToMenu MenuResizeNotAllowed
+ Window can't be resized!!! Nop
I don't think that the user should care about this, fvwm should handle
it:
If there is a binding to C, and no binding to M, H, or D,
and the user presses the button down and moves the mouse,
fvwm should jump out of the function instead
of waiting for button release.
I played for a while with openbox replicating most of my window
move and resize bindings and I could not reproduce any of the issues I
descibed so far.
If openbox can, why can't fvwm? There is evidently a way to handle
this.
This issue was already in fvwm 2.4. But here's it's tricky to spot:
the screen is frozen while it happens, so top/xterm don't update.
Instead of just burning CPU as vers. 2.4.x, 2.5.x/2.6.x
seem to cause additional load on my graphics board.
It starts to whistle, which is very annoying.
Best regards,
Axel
Original-Nachricht
Datum: Wed, 6 Jun 2012 14:48:55 +0100
Von: Thomas Adam tho...@fvwm.org
An: Axel Rohde dr.a.ro...@gmx.de
CC: Thomas Adam tho...@fvwm.org, fvwm-workers@fvwm.org
Betreff: Re: fvwm burning CPU on Move-or-Raise, Resize-or-Lower functions
On Thu, May 31, 2012 at 07:49:24PM +0200, Axel Rohde wrote:
Hi Thomas,
on a SuSe system at work I found a system.fvwm2rc apparently authored by
you. I appended those parts of my config that reproduce the issue on
my PC at the end of the file.
So the CPU usage here is because we lock and wait, whilst the button is
held
down, having grabbed the server, because whilst the curosr is down, the
cursor is changed, whilst we do nothing, because the resultant operation
is
a no-op -- we're just waiting for WaitForButtonsUp() to complete all the
time.
So after *all* of that, and leading me all around the houses, all you
needed
to have said originally was:
FixedSize/FixedPosition windows cause CPU to increase when a function is
run on such windows. Here's the Styles and function I'm using.
Nevermind though. :)
Nothing I want to do about this -- and nothing I can do about this,
because
the pointer is grabbed throughout the lifetime of the function being run.
-- Thomas Adam
--
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a