After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319682 - Add per-process CPU history usage graph ("sparklines")
Add per-process CPU history usage graph ("sparklines")
Product: system-monitor
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
Depends on:
Reported: 2005-10-24 22:21 UTC by Dave Malcolm
Modified: 2018-05-22 11:58 UTC
See Also:
GNOME target: ---
GNOME version: ---

new GtkCellRenderer subclass implementation (12.32 KB, text/x-csrc)
2005-10-24 22:22 UTC, Dave Malcolm
header file for the above (2.41 KB, text/x-chdr)
2005-10-24 22:22 UTC, Dave Malcolm
Initial version of patch to wire this up (7.60 KB, patch)
2005-10-24 22:28 UTC, Dave Malcolm
none Details | Review
Screenshot of this (125.81 KB, image/png)
2005-10-24 22:30 UTC, Dave Malcolm
Updated version of sparkline cell renderer (cleaning out dead code) (10.69 KB, text/x-csrc)
2008-05-10 17:52 UTC, Dave Malcolm
Updated version of patch (3.93 KB, patch)
2008-05-10 17:58 UTC, Dave Malcolm
none Details | Review

Description Dave Malcolm 2005-10-24 22:21:12 UTC
I'm about to attach a first pass at some code which implements a "sparkline"
GtkCellRenderer subclass, and a patch to procman which uses it to add
per-process CPU % history.

The patch isn't done yet, and suggestions are welcome on how best to integrate
this.  Federico was suggesting on IRC that this could be implemented for memory
usage as well, so that you can see trends on memory usage per-process (e.g. to
quickly spot memory leaks by visual scanning)
Comment 1 Dave Malcolm 2005-10-24 22:22:15 UTC
Created attachment 53849 [details]
new GtkCellRenderer subclass implementation
Comment 2 Dave Malcolm 2005-10-24 22:22:44 UTC
Created attachment 53850 [details]
header file for the above
Comment 3 Dave Malcolm 2005-10-24 22:28:39 UTC
Created attachment 53852 [details] [review]
Initial version of patch to wire this up

This is currently a bit of a mess, but I wanted to get feedback before
progressing further with this.

Something I tried to implement which isn't working yet is to redefine the
concept of an "Active Process" as being one which has had activity in the
period shown in the sparkline, also, to redefine the sort order so that %CPU is
sorted by the areas under the graph (currently processes leap around a bit too
much when sorted that way)
Comment 4 Dave Malcolm 2005-10-24 22:30:46 UTC
Created attachment 53853 [details]
Screenshot of this
Comment 5 Dave Malcolm 2005-10-24 22:34:36 UTC
Cell renderer has a "filled" boolean attribute which is set for the screenshot;
I think this makes sense for this case for a resource usage case (since you can
visualise cost as the area under the graph); if you set this to false you get a
simple line.

I think I've slightly messed up the clipping; there's meant to be a little red
dot showing the current state, right-aligned.

The cell renderer takes a GArray of double, assumed to be in the range 0.0 - 1.0
Comment 6 Dave Malcolm 2005-10-24 22:41:28 UTC
CCing federico and duffy as both have expressed an interest in this.

Ideally I'd like the new cell renderer to land in GTK, but obviously it will
need some more design and usage in other situations (e.g. gnumeric, network
interface selection, evolution????)
Comment 7 Benoît Dejean 2005-10-24 22:49:20 UTC
Thanks. I had put this on my todo.

Putting the graph in the CPU col looks weird to me. I would have make
per-process-CPU/Memory/Whatever-usage graph on demand. I'd like to keep g-s-m as
light as possible. Your changes to src/proctable.c make updates much more expensive.

What about putting these kind of graphs to a new window, just like memory maps
or openfiles ? Then you could use the same graph widget than the resource view.
Comment 8 Dave Malcolm 2006-02-15 01:33:53 UTC
I think the value of embedding the graphs in the process view is that that's where the per-process information is listed.  I'd have it as an option for that view, rather than a separate view, and enable it by default.

To use Tufte's jargon, the column then becomes a set of "small multiples" where the values are easily compared.

Is gnome-system-monitor aimed purely as a graphical replacement for "top", or are there other goals?  Who is the target user, and what are they using it for?

My primary use of sparklines is when I'm wondering why my CPU spiked 10
seconds ago and I only just got control back over the UI (by which time
the constantly shifting CPU stats aren't helpful - what if the process
isn't around anymore?)
Comment 9 Tomasz Torcz 2006-08-25 08:55:16 UTC
Fedora's graphical tool to manage Xen VMs implements CPU usage sparkline.
It would be nice to have in GNOME System Monitor.
Comment 10 John Stowers 2007-01-03 13:07:14 UTC
Any movement on this? I would find it particuarly helpful in system-monitor
Comment 11 Kevin Duffus 2007-08-25 20:06:51 UTC
I'd like to also see this implemented. Please consider its integration
Comment 12 Benoît Dejean 2007-08-25 21:20:32 UTC
I'd like to, but in this way. On a 1GHZ CPU, system-monitor alread eats to 25% CPU ... i'm not proud of it.
Comment 13 Karl Lattimer 2007-12-11 16:48:42 UTC
This is a great feature, I'd love to see it too, so I'll take a look at getting the cpu consumption down. This will involve profiling the renderer, ensuring that only on screen cells are rendered and maybe various other tweaks. This will need testing on intel, ati and nvidia as the 2D performance differs drastically on each.

In more general terms GSM needs profiling. This will probably have to wait until after 2.22 is out. So I hope to get this in by gnome 2.24 :)
Comment 14 Benoît Dejean 2007-12-11 17:03:25 UTC
Have a look at how much CPU the resources tab takes :/
The proctable already uses a lot of CPU (mainly because of the writable memory column), i'm really concerned about CPU usage, it should stay < 5% on a 2GHZ CPU.
Comment 15 Dave Malcolm 2007-12-19 17:13:24 UTC
One profiling thought: how much CPU is taken on the rendering, vs the gathering of the data?  One way to measure this might be to render it with the CPU usage of every process hardwired to 100%, rather than reading /proc
Comment 16 Dave Malcolm 2007-12-19 17:22:05 UTC
Forgot to add: this would involve hardwiring all the data; is it possible to supply a mock implementation of the process data, so that you have a hardcoded list of e.g. 20 processes.  What does the CPU load look like then? (using top or something else to measure gnome-system-monitor itself, of course!)
Comment 17 Dave Malcolm 2008-05-10 17:52:45 UTC
Created attachment 110687 [details]
Updated version of sparkline cell renderer (cleaning out dead code)
Comment 18 Dave Malcolm 2008-05-10 17:58:39 UTC
Created attachment 110688 [details] [review]
Updated version of patch

I've updated the patch, from the old one against CVS C code to the SVN C++ code (pre the gio merge since I don't have that handy on this machine); so this is against svn r2399.

Updates are an issue; the cell column only gets redrawn when the CPU value changes, not when the array of values scrolls (so you get weird-looking updates when mouseovering idling processes).  Fixable, but not sure of performance impact.  Perhaps issue a call to gtk_tree_model_row_changed when the array scrolls, but only if the scrolled value != new value (if that makes sense)
Comment 19 Robert Roth 2012-07-24 20:43:46 UTC
Removing assignee, as there has been no progress on this in the last 4 years.
Comment 20 GNOME Infrastructure Team 2018-05-22 11:58:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: