| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
