| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
I planned to use the 256-colors for differentiating graphs in
other row types, but it's becoming clear saving space is more
important.
So this cuts the file size down further quite a bit:
-rw-r--r-- 1 vc vc 219323 Sep 19 01:37 09.19.24-01:36:43-2.png
Becomes:
-rw-r--r-- 1 vc vc 152674 Sep 21 14:25 09.21.24-14:25:16-2.png
|
|
This introduces a LUT indirection table for mapping the raw layer
values to a dense, deduplicated palette used with the PNG.
This should help with compression ratios at basically no cost.
Before `1800x8000 --headless --snapshot 10 --hertz 60`:
-rw-r--r-- 1 vc vc 87873 Sep 19 01:36 09.19.24-01:36:43-0.png
-rw-r--r-- 1 vc vc 215719 Sep 19 01:36 09.19.24-01:36:43-1.png
-rw-r--r-- 1 vc vc 219323 Sep 19 01:37 09.19.24-01:36:43-2.png
-rw-r--r-- 1 vc vc 221979 Sep 19 01:37 09.19.24-01:36:43-3.png
After:
-rw-r--r-- 1 vc vc 72303 Sep 19 01:37 09.19.24-01:37:30-0.png
-rw-r--r-- 1 vc vc 174100 Sep 19 01:37 09.19.24-01:37:30-1.png
-rw-r--r-- 1 vc vc 177430 Sep 19 01:37 09.19.24-01:37:30-2.png
-rw-r--r-- 1 vc vc 178711 Sep 19 01:38 09.19.24-01:37:30-3.png
Without any increase in compression level used. Which while it
would improve ratios further, substantially increases CPU cost.
|
|
It'd be nice to allow the last partial row to be rendered, but
as-is it can result in segfault for some operations that aren't
clipping at that granularity.
Another option is to always round up the bits allocation to the
ROW_HEIGHT boundaries, then not worry about this, and do the
partial clip @ serialization to png time.
|
|
Increasing contrast a bit for odd rows / separators
|
|
This should have been changed when transitioning to nibbles and
the separators became generated @ present time when serializing
to png.
The first pass clears the shadow layer while assigning the first
offset part of the shadow. But it was staying within the
separators, which is now resulting in small bits of littered
shadow corruption in the separators barely visible in the PNGs.
Fix is trivial; initialize the separator bits when shadowing the
row as well.
|
|
Eventually this should get applied semi consistently to all
snapshots, but I'm most annoyed by its omission from the
--headless PNGs at the moment.
Also it arguably makes sense to always start with extending the
constrained mem-to-png case where we're working with a 256-color
palette, since the Xlib/XRender case has effectively no
constraints. Or just abandon any hope of preserving consistency
across the rendered output modes..
|
|
There's still assumptions that everything in the hierarchy fits
within the canvas... the Xlib stuff would clip all this behind
the scenes, but vcr/headless mode doesn't have such guard rails.
At some point I need to sit down and do a thorough pass in this
vein... Fortunately most my headless use cases have the canvas
configured appropriately.
|
|
8 layers is no longer supported as a future expansion path...
|
|
These snuck in during the Xlib->vcr refactor which involved a lot
of copy-n-pasta taking Xlib sections from charts.c
|
|
This mostly works, but the maintenance of text shadows are a
gross naive conversion of the pre-nibbles code. It would
probably be better to add the shadows @ mem->png serialization
time and not bother maintaining them at all for headless.
It seems to work well enough to exercise and evaluate memory
footprints though...
The reason for "nibbles" is to save memory. Prior to this, the
mem backend would use a byte per pixel of layer information. By
not storing the background layer in this space, the current set
of layers used can fit in 4 bits (aka a nibble).
So this commit pivots to packing two pixels worth of layer data
into each of those bytes, effectively cutting the memory
requirements of the mem backend (headless mode) in half.
It matters for embedded use cases. The next step from here to
use substantially less memory in headless mode would require a
deeper refactor where we don't maintain a bitmap style
representation at all. It's doable, but not in the cards for my
free time right now.
|
|
|
