Hi all, I've made an observation on my laptop while commuting every morning between home and work. Process are consuming cpu time even when not used and moreover when not top windows. For example, virtual box still consumes cpu even when paused. From this simple fact I've come to the point that there could be a way to enhance battery consumption developing (4 lines changes) in kwin. My idea was originally to add an extra windows decoration button to SIGSTOP/SIGCONT. But I've thoug h a bit further that having a window client sigstop would not be beautiful and graphically glitchy. So I decided to enhance the Shade state of a window. After few minutes to get kde-workspace bundle compiling on kubuntu (so much stuff to do ! from missing package to tweak of link.txt due to libICE and libSM). I've modified the kwin sources (see attached patch below) and the Client::killProcess to use a custom signal sent to the process. It's pretty handy to, for example, pause chrome or firefox while in the train without a wifi access which dramatically reduce the global laptop consumption. An enhancement of this patch would be to transform it as an option of KWin to choose whether or not to pause the process when shaded. Hope that it will be useful for others. Olivier. *** kde-workspace-4.8.2/kwin/client.cpp 2012-03-30 00:02:32.000000000 +0200 --- ../kde-workspace-4.8.2a/kwin/client.cpp 2012-04-23 08:43:34.212127738 +0200 *************** void Client::setShade(ShadeMode mode) *** 1128,1129 **** --- 1128,1131 ---- } + // STOP processus + killProcess(SIGSTOP, false); } else { *************** void Client::setShade(ShadeMode mode) *** 1139,1140 **** --- 1141,1144 ---- workspace()->requestFocus(this); + // CONT processus + killProcess(SIGCONT, false); } *************** void Client::killWindow() *** 1436,1438 **** Notify::raise(Notify::Delete); ! killProcess(false); XKillClient(display(), window()); // Always kill this client at the server --- 1440,1442 ---- Notify::raise(Notify::Delete); ! killProcess(SIGTERM, false); XKillClient(display(), window()); // Always kill this client at the server *************** void Client::pingTimeout() *** 1483,1488 **** ping_timer = NULL; ! killProcess(true, ping_timestamp); } ! void Client::killProcess(bool ask, Time timestamp) { --- 1487,1492 ---- ping_timer = NULL; ! killProcess(SIGTERM, true, ping_timestamp); } ! void Client::killProcess(int signal, bool ask, Time timestamp) { *************** void Client::killProcess(bool ask, Time *** 1502,1505 **** } else ! ::kill(pid, SIGTERM); ! } else { process_killer = new QProcess(this); --- 1506,1511 ---- } else ! ::kill(pid, signal); ! } ! // only SIGTERM when asking ! else if (signal == SIGTERM) { process_killer = new QProcess(this); *** kde-workspace-4.8.2/kwin/client.h 2012-03-30 00:02:32.000000000 +0200 --- ../kde-workspace-4.8.2a/kwin/client.h 2012-04-23 08:43:59.543811048 +0200 *************** private: *** 547,549 **** void pingWindow(); ! void killProcess(bool ask, Time timestamp = CurrentTime); void updateUrgency(); --- 547,549 ---- void pingWindow(); ! void killProcess(int signal, bool ask, Time timestamp = CurrentTime); void updateUrgency(); Reproducible: Always
abusing shade is probably not an option, since a) shading is no more commonly known/used b) would be unexpected side-effect (you actually don't want to stop the process if you shade a window) which might even cross regular STOPs/CONTs c) actually you'd have to shade all clients of a group, otherwise you'd shade a client, stop the process and encounter unresponsive other windows d) the existence of SIGSTOP/SIGCONT is probably known faaaar less - users would think the app crashed if they somehow encounter the state (see above, but also a WM restart or whatever) -- a) why do you not just STR your notebook when not using it? b) doesn't actually vbox have a play/pause button? c) kill -STOP `xprop | grep PID | sed -e 's/.*= *//'` (one could make this more complex, setting/removing a property on the window to hint the current state and toggle on it) -- aside my questions and the issues with abusing shading, propagating the ability to play/pause an application to more "common" users sounds like an interesting idea (but because we cannot pause "windows" i'm not entirely sure whether the WM is the ideal place for this at all)
Dear Thomas, Firstly, thanks for your interest in my post :) (In reply to comment #1) > abusing shade is probably not an option, since > a) shading is no more commonly known/used That is true, and therefore, let's revive it with new interests. > b) would be unexpected side-effect (you actually don't want to stop the > process if you shade a window) which might even cross regular STOPs/CONTs That is why I mentioned to let this be an option of kwin. > c) actually you'd have to shade all clients of a group, otherwise you'd > shade a client, stop the process and encounter unresponsive other windows Clearly, I've not seen this problem, probably because I'm not a group fan :) multiple workspace are enough for me. > d) the existence of SIGSTOP/SIGCONT is probably known faaaar less - users > would think the app crashed if they somehow encounter the state (see above, > but also a WM restart or whatever) Yes, hopelessly, but when shaded, as the client app is not displayed anymore, then the user might notice it could have crashed (and moreover, if option is not enabled, the process would not be paused) > > -- > > a) why do you not just STR your notebook when not using it? Well, the fact is that during my commiting I'm coding ! and therefore only using kate/konsole. So STRing the pc is not an option :) > b) doesn't actually vbox have a play/pause button? That is something I'm already using, BUT vbox stil consumes ~10% cpu while in pause ... which is totally abused looking at what it's required to do. Firefox/chrome/skype and such application you don't want to loose the state but you don't care while not connected are subject to my pausing mechanism. > c) kill -STOP `xprop | grep PID | sed -e 's/.*= *//'` (one could make this > more complex, setting/removing a property on the window to hint the current > state and toggle on it) You're right, tagging windows to be paused is an interesting path to follow. > > -- > > aside my questions and the issues with abusing shading, propagating the > ability to play/pause an application to more "common" users sounds like an > interesting idea (but because we cannot pause "windows" i'm not entirely > sure whether the WM is the ideal place for this at all) The WM is not forcefully the best place, but that was where the smallest amount of code was necessary :D. I do agree totally. pausing is interesting for applications that are linked to an activity which is "paused" because of the lack of required feature (no network ...) or when an activity is flagged as power consumer and therefore the user would want to have it disabled when unplugged. Probably I shall have the idea posted somewhere explaining the power consumption issues. But the fact is that I just don't know where to explain all this ... (which is only targetting a few users moreover). Cheers, Olivier
*** Bug 313429 has been marked as a duplicate of this bug. ***
I added but 313429 because I could not find anything about suspend / continue, so I'll just add my remark here - I think it would be useful if it would go as a window decoration under 'More actions' and toggles to 'continue' if the process is suspended. For the user-friendliness - maybe the name 'Pause' / 'Unpause' would be more appropriate?
Adding such behavior to shaded windows doesn't seem right. Even though a window is shaded or minimized, the app may still need to continue running, e.g. to play music. There are also other issues as pointed by Thomas.