On a multiprocessing system other processes, which don't currently have your
attention, may still bog down the system. Many windows are quite active
browsers, windoze emulators... This can make especially slower PCs sluggish
when many windows are open. There are two things one could do about this:
- Different priorities: You could dynamically assign different
priorities, highest for the processes associated to the focused window, next
highest for other visible windows, somewhat lower for occluded windows or
those on other viewports and lowest for iconified ones or those on other
workspaces. Alas Unix allows you to lower the priority at will, but only a
process with root permissions could bring them back up.
- Stopping and continuing: Sort of an extreme case of the previous,
where processes either run or don't at all. Quite a few programs painlessly
(or almost) support a STOP signal, completely turning them off temporarily and
a CONT signal at a much later time. At least on XFree86 the server
connection doesn't time out.
If you stop the right ones, the overall speed of your PC increases noticeably.
"Top" can give you a good indication of which processes those are. The speed
when getting big processes back may hurt a little, because they may have been
completely swapped out after a while. But it's still faster than starting
them from scratch.
You can let the stopping and awakening of processes occur based on workspace
switching. Any auto-stoppable window that does not appear on the current
workspace is then stopped. When you get back to its workspace it gets awakened
If instead you use viewports that is also possible. Any auto-stoppable window
that does not appear on the current viewport is stopped. If you use both
workspace and viewports in combination, you may set both. But maybe, like I
do, you've got the browser and mailer on different viewports of your internet
workspace and communicate between them frequently. Then you should choose only
workspace based stopping.
Determining the PIDs
Traditionally X11 is weak for mapping windows to system processes responsible
for them. There is an X-window property _NET_WM_PID for this, but few
application set it yet. And when they do, it may represent the process or
thread responsible for the GUI, not the one that's wasting CPU. The
following mechanism is applied here:
- If the window has a (sawfish) property pids, which is a list of numbers, those are the pids.
- If that property holds a string, it is a regexp matched against the output of auto-stop-ps-command. This is best set through matched windows in the GUI. When this gets called, all windows having a regexp that matches at least one line of output are processed at once.
- If that property holds a function, it is called and should return a list of numbers (1 at least).
- If none of the above apply, the X-window property _NET_WM_PID is checked.
- If that doesn't exist, you are prompted for one or more space separated numbers.
- In all cases, the numbers are stored in property pids for future access.
- Stopped windows holding the X selection can not honour requests for it, blocking the requesting window till it times out.
- Component mechanisms like KDE's dcop or Gnome's bonobo will fail if the targeted window is stopped.
- Stopped windows running some protocol with a keep alive element to another server, may time out.
Version 0.1 (2002-11-30)
- Also optionally auto-stop when shaded or iconified.
- Stop only after a timeout to let the program finish some task.