diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2024-09-21 17:22:35 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2024-09-21 17:22:35 -0700 |
commit | 0090477d85c61c456979aa18ac18ec4ec2260113 (patch) | |
tree | 0627af2d074dd3c9a11440812832a7d89a845752 /src/vcr.c | |
parent | 8a49d1650f8b7c223c921af0bbf6f5204b93402e (diff) |
charts: scale % bars by num_cpus when appropriate
For rows reflecting threads and single/non-threaded processes,
let's scale the bar % by the number of cpus, so they can use the
full height of the row.
These tasks can't scale to multiple CPUs, so it's pointless to
leave vertical space for the other cores' capacity, if present.
For multi-threaded process rows, the vertical space continues to
accomodate all cores.
I've been on the fence about this change for a while because it
increases the cognitive load of reading the graphs, now the
scales are inconsistent. But when you've got 16 cores like on my
AMD P14s thinkpad, combined with a row height of 16 pixels, you
start wishing these rows used the full height of the row for
their single-core-constrained %ages.
Diffstat (limited to 'src/vcr.c')
-rw-r--r-- | src/vcr.c | 4 |
1 files changed, 4 insertions, 0 deletions
@@ -1194,6 +1194,10 @@ void vcr_draw_bar(vcr_t *vcr, vcr_layer_t layer, int row, double t, int min_heig if (height < min_height) height = min_height; + /* clamp the height to not potentially overflow */ + if (height > (VCR_ROW_HEIGHT - 1)) + height = (VCR_ROW_HEIGHT - 1); + switch (vcr->backend->type) { #ifdef USE_XLIB case VCR_BACKEND_TYPE_XLIB: { |