https://bugs.kde.org/show_bug.cgi?id=434040
Arjen Hiemstra changed:
What|Removed |Added
Resolution|--- |NOT A BUG
Status|REPORTED|RESOLVED
--- Comment #2 from Arjen Hiemstra ---
Please don't put multiple issues in one report, it makes it hard to deal with
the individual issues.
> But KSysguard solved that more nicely, by first shrinking the legend to just
> colored percentages. You should still wrap them at some point, because
> otherwise 48 threads will fit on pretty much no screen, but having a colored
> line next to it is not very useful at that size.
This may be tweaked later, but KSysGuard's solution also does not scale too
well and additionally has quite some contrast problems.
> Secondly, the default of using a stacked chart leads to a chart going to
> 1600%, but because only one core is pinned, that one sits at 1/16th of the
> chart. This does not provide much useful information about why an application
> hangs, since it looks like it is hanging in IO instead of in a CPU loop.
Seems to me this is better solved by the process table? How would you even
distinguish single process usage from the history chart? In any case, stacked
means you get to see individual core usage as well as overall usage and in my
opinion it is actually easier to distinguish cores, even with lower fill
opacity the screenshot of KSysGuard is pretty useless to me. That said, this is
why the entire thing is configurable so you can choose not to use stacked (and
as David said, you can also choose the fill opacity.)
--
You are receiving this mail because:
You are watching all bug changes.
