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 635939 - [patch] cpu usage graph unusable for 4+ cpus/cores
[patch] cpu usage graph unusable for 4+ cpus/cores
Product: system-monitor
Classification: Core
Component: resources
git master
Other All
: Normal enhancement
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
: 466006 498874 668929 (view as bug list)
Depends on:
Reported: 2010-11-27 19:05 UTC by Eugen Anghel
Modified: 2012-11-09 20:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

draw the CPU graph as a stacked area chart (2.19 KB, patch)
2010-11-27 19:05 UTC, Eugen Anghel
none Details | Review
normal line graphs (105.57 KB, image/png)
2010-11-27 19:07 UTC, Eugen Anghel
stacked area graph (89.26 KB, image/png)
2010-11-27 19:09 UTC, Eugen Anghel
Temporary workaround for CPU with more than 4 cores (1.80 KB, patch)
2011-03-26 08:04 UTC, Marc-Antoine Perennou
reviewed Details | Review
Proposed patch updated (3.05 KB, patch)
2012-08-10 20:07 UTC, Robert Roth
none Details | Review

Description Eugen Anghel 2010-11-27 19:05:57 UTC
Created attachment 175370 [details] [review]
draw the CPU graph as a stacked area chart

On a quad-core machine, the CPU usage graphs become so intertwined that it becomes very hard to see the actual total usage, or even to follow one of the lines. I propose using stacked area graphs. I have attached a patch that implements this and a pair of before and after screenshots.

There is a drawing glitch with the patch that I can't seem to resolve (see the right side of the 2nd screenshot).
Comment 1 Eugen Anghel 2010-11-27 19:07:48 UTC
Created attachment 175372 [details]
normal line graphs
Comment 2 Eugen Anghel 2010-11-27 19:09:05 UTC
Created attachment 175373 [details]
stacked area graph
Comment 3 André Klapper 2011-03-25 22:10:13 UTC
*** Bug 645662 has been marked as a duplicate of this bug. ***
Comment 4 Marc-Antoine Perennou 2011-03-26 08:04:35 UTC
Created attachment 184271 [details] [review]
Temporary workaround for CPU with more than 4 cores

Use the same color for cpu0, cpu4, cpu8, etc
This at least allows to have an infinite number of cores, not being limited by the schema.
Comment 5 Chris Kühl 2011-03-26 12:29:35 UTC
Review of attachment 184271 [details] [review]:

This is definitely a band-aid for something that needs a more thoughtful fix. I'm looking into it. May ask for a hard freeze exception for this work-around patch. Thanks.
Comment 6 Robert Roth 2012-01-06 21:36:13 UTC
Bug #632188 contains a patch which works for an unlimited number of cores, by putting the list of colors in one GSettings key as a comma separated list of strings. This lets the user set a color separately for each core, and is not limited by the schema.
Comment 7 André Klapper 2012-01-28 23:05:47 UTC
*** Bug 668929 has been marked as a duplicate of this bug. ***
Comment 8 André Klapper 2012-02-26 10:46:27 UTC
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on when the assignee is changed to an individual.]
Comment 9 Robert Roth 2012-08-08 19:11:48 UTC
I absolutely like this stacked chart idea, as it clearly improves the situation on systems with many cores, and also helps user deciding the average CPU usage (fixing bug 498874).
Comment 10 Robert Roth 2012-08-08 19:45:16 UTC
*** Bug 498874 has been marked as a duplicate of this bug. ***
Comment 11 Robert Roth 2012-08-10 20:07:20 UTC
Created attachment 220908 [details] [review]
Proposed patch updated

I have updated the attached patch to work with the latest trunk.
Comment 12 Robert Roth 2012-11-09 20:08:24 UTC
*** Bug 466006 has been marked as a duplicate of this bug. ***
Comment 13 Robert Roth 2012-11-09 20:10:15 UTC
I have added an option in the preferences to turn on CPU stacked area chart display, the option defaults to false for now, you will have to turn it on manually. If it gets positive overall feedback, we might enable it later by default.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.