summaryrefslogtreecommitdiff
path: root/src/vcr.c
AgeCommit message (Collapse)Author
2024-10-16vcr: prevent row overflow in mem vcr_draw_text()Vito Caputo
Another row clipping check off by one, it'd be nice to make this draw text into partial rows... but this as-is may just scribble.
2024-10-12vcr: more assertsVito Caputo
2024-10-08vcr: switch to ppoll() and return microseconds delayVito Caputo
This is mostly preparotory for having more precision in a computed delay, but is also arguably just finishing what was started when adding the _us suffixes throughout. A future commit should also rework signal stuff to only unblock signals in ppoll().
2024-09-29vcr: clarify timeout units in namingVito Caputo
vcr_backend_poll() mirrors the poll() api, but let's clarify the timeout units as microseconds.
2024-09-21charts: scale % bars by num_cpus when appropriateVito Caputo
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.
2024-09-21vcr: use 4-bit/16-color PNG in mem_to_pngVito Caputo
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
2024-09-19vcr: densify+deduplicate mem_to_png paletteVito Caputo
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.
2024-09-15vcr: bump row clipping to not attempt partial row operationsVito Caputo
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.
2024-09-09vcr: lighten grays used in PNG output rowsVito Caputo
Increasing contrast a bit for odd rows / separators
2024-09-09vcr: clear shadow layer for entire rowVito Caputo
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.
2024-09-07vcr: alternate row backgrounds in headless snapshotsVito Caputo
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..
2024-09-07vcr: more row overflow crash preventionsVito Caputo
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.
2024-08-31vcr: update stale comment about layer countVito Caputo
8 layers is no longer supported as a future expansion path...
2024-08-31vcr: trailing whitespace cleanupsVito Caputo
These snuck in during the Xlib->vcr refactor which involved a lot of copy-n-pasta taking Xlib sections from charts.c
2024-08-27vcr: represent mem backend layers in nibblesVito Caputo
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.
2024-08-13charts: first stab at factoring out Xlib from charts/vmonVito Caputo
© All Rights Reserved