Since a while I've had the idea that the window manager should give visual cues as to which process is loading the cpu / a cpu core the most.

Now with multicore systems, one may not notice if there's a firefox instance with flash hogging one cpu, but on a laptop running on batteries this may have a nasty impact.

So the idea I had is that the window manager should give visual cues as to what the processes behind a specific window 'cost' in terms of cpu power.

The window could get a glow that goes from green (low cpu load) to orange (medium load) to red (high load) and even starts pulsating if it's really taking up a cpu core completely. The titlebar could also change colour or so, etc.

That's a really nice idea . I think I wouldn't have it enabled all the time, but I would like to have it (so my vote goes for "I would like this."). Maybe you could add it as idea to brainstorm.php ? It is for sharing such ideas.

This is a really innovative idea.

DO WANT!

I like the idea. One suggestion would be to limit the effect to the title (and border) - it would not bode well to have the entire window start glowing different colors as you use it.

Nice idea but impossible to implement because:

1) X doesn't provide CPU load for individual windows,
2) The WM cannot poll the kernel for process CPU load as it would interfere with compositing response times as well as increasing the WM's system load to unacceptable levels,
3) Even if it could poll there's no easy way to map processes to X windows, and
4) Some weird window tricks exist that applications use and will interfere with this idea but are invisible to the user (Flash in web browsers for an example).

Sorry if these are stupid (I've never done any WM development), but I have a few questions for you:

Zarin wrote:Nice idea but impossible to implement because:

1) X doesn't provide CPU load for individual windows,

You can't, obviously, get the CPU load of an error dialog, for example, but why not get the load of it's parent window and color it the same way?

Zarin wrote:2) The WM cannot poll the kernel for process CPU load as it would interfere with compositing response times as well as increasing the WM's system load to unacceptable levels,

Can't you start a thread that polls the CPU load at some intervals second and updates the shadow color?

Zarin wrote:3) Even if it could poll there's no easy way to map processes to X windows, and

If you open KRunner's system activity view (Ctrl+Esc), the processes that have windows have the icon and the title, so there is a way to match them... And if it's a dirty hack would that be a problem since it's all in a separate plugin anyway?

Zarin wrote:4) Some weird window tricks exist that applications use and will interfere with this idea but are invisible to the user (Flash in web browsers for an example).

Flash does not have a border glow anyway, so it shouldn't be a problem. However it is a child process of the browser, so couldn't the parent just inherit the load?

Alec wrote:If you open KRunner's system activity view (Ctrl+Esc), the processes that have windows have the icon and the title, so there is a way to match them...

Interesting, I've never noticed that. I guess I'll need to discuss some things with the author of the system activity application--whoever that is.

I had similar thoughts to what Alec brought up.
When a window is created it has to be associated with some process, after all the WM needs know which process to send the close/kill signals to when you hit the close button or tell the WM to kill the window('s process). Then you also need to sum up the cpu load of all sub-processes to that process (to account for things like Firefox+Plugins, or other windows which use sub-processes for various tasks) (except for those sub-processes which have their own windows).
Of course in the case where multiple windows are associated with the same process (dialogs and their parents), they would all share the same load coloration.

airdrik wrote:... after all the WM needs know which process to send the close/kill signals to when you hit the close button or tell the WM to kill the window('s process).

Actually that is completely wrong. X abstracts all this so the WM doesn't actually know directly which process controls which window. If the WM wants to close a window it sends a signal to the X window and when the process gets around to processing all it's new signals for its windows it detects the close signal and begins the shutdown process itself. Kill signals are done by passing the window ID to the XKill() function and lets X kill the process.

By the look of it the programs that have icons and window in the system activity window are windows that have a _NET_WM_PID property. This property has the process ID the window is running under and therefore the WM/other applications can link the two. As this is an optional extension to the X property specifications there is no guarantee that applications actually use it.

Zarin wrote:

airdrik wrote:... after all the WM needs know which process to send the close/kill signals to when you hit the close button or tell the WM to kill the window('s process).

Actually that is completely wrong. X abstracts all this so the WM doesn't actually know directly which process controls which window. If the WM wants to close a window it sends a signal to the X window and when the process gets around to processing all it's new signals for its windows it detects the close signal and begins the shutdown process itself. Kill signals are done by passing the window ID to the XKill() function and lets X kill the process.

Oh, I didn't realize that. That makes sense, though since the WM generally doesn't need to know the process ID for a given window, it just needs to know about windows so it can manage their placement/movement/hiding/etc. That certainly puts a damper on things, unless there is a way to ask X for the Process ID (which I assume not, otherwise you would have found it).

Zarin wrote:By the look of it the programs that have icons and window in the system activity window are windows that have a _NET_WM_PID property. This property has the process ID the window is running under and therefore the WM/other applications can link the two. As this is an optional extension to the X property specifications there is no guarantee that applications actually use it.

I suppose you could implement it using this property if available, though probably not the best idea since it would only work with some applications and not universally.

Of course I'm not terribly disappointed if this doesn't make it. I don't think I, myself would ever use it, and I would expect that only a very select group of individuals would use it.

airdrik wrote:I suppose you could implement it using this property if available, though probably not the best idea since it would only work with some applications and not universally.

Although it's optional both Qt and GTK+ use the property meaning that the majority of desktop applications actually have it set.

I have just read all replies here, and also entered this idea in the brainstorm section.

Some comments to the comments here...

Thanks for the replies, and good to know that you like this idea.

As for the way to actually visualise this, yes, it shouldn't be the whole window, just the border/shade/whatnot. Configurable, naturally.

As to the system load caused by this, and the way to implement it,...

What I'd do (if I had time and the required programming skills) is just check with top if there is a high cpu load. If not, don't do anything.
I actually have a gkrellm open on all my systems, which shows the load, so I immediately spot high loads / weird stuff.
But on my laptop with a small screen, the window I'm using may be maximised and in the foreground, thus covering the gkrellm.

In any case, checking the cpu(s) load should not cost too much, as many programs/applets/widgets check it.
Once the cpu load (of one core, in a multicore system) goes over 50% (or so), one could check which processes are taking up the core/cpu, and check if a single process is responsible for at least 40% (or so - please take all numbers as example numbers from now on) cpu load.
Perhaps using the PID and PPID it's possible to find out which windowed processes are related to the high load processes, and the window decoration/colour can be changed accordingly.

Once the cpu load goes over 90%, perhaps some more effort could be invested, such as checking which windows actually have child processes that combined take more than 50% cpu cycles.