Continuing from the previous commit, this shifts:
* In-memory data -> temporary file
* Image decoding -> background thread
The background thread asynchronously decodes frames and
sends them to the render thread via a bounded channel.
While decoding frames, it writes them, uncompressed, to
a scratch file so that when the animation loops, it is
a very cheap operation to rewind and pull that data
from the file, without having to burn CPU to re-decode
the data from the start.
Memory usage is bounded to 4 uncompressed frames while
decoding, then 3 uncompressed frames (triple buffered)
while looping over the rest.
However, disk usage is N uncompressed frames.
refs: https://github.com/wez/wezterm/issues/3263
This makes decoding animation frames a lazy operation, but it
comes at the cost of needing to re-decode the image from scratch
when it loops, because the image crate doesn't provide a way
to rewind its frame iterator.
That initial decode can have a significant time cost; a small
webp file consistently takes 150ms to decode, which is too
much to do inline in the render thread.
Next steps will be to move that cost off the render thread.
Rust 1.67, released today, is a bit more particular about the layout
of the memory used in TeenyString and segfaults in the test suite.
On closer inspection, our Drop impl was casting to Vec<u8> instead of
TeenyStringHeap and the fault was freeing bogus memory within that
region.
Fixing the cast to the correct type resolves the issue.
When a line is rapidly updated with only some of the cells being
actually changed (eg: progress counter or other status being frequently
updated), it is desirable to avoid paying the cost of shaping the entire
line.
When bidi is not enabled we can assume that it is safe to break clusters
on whitespace boundaries. Doing so allows each of those whitespace
separated words to be shaped and potentially cached independently,
which reduces the amount of CPU time spent for the whole line.
This commit just adjusts the clustering, which reduces the CPU
utilization a bit.
refs: https://github.com/wez/wezterm/issues/2701
I spent a few hours in heap profilers. What I found was:
* Inefficient use of heap when building up runs of
`Action::Print(char)`.
-> Solve by adding `Action::PrintString(String)`
and accumulating utf8 bytes rather than u32 codepoints.
* Inefficient use of heap when building Quad buffers: the default
exponential growth of `Vec` tended to waste 40%-75% of the allocated
capacity, and since we could keep ~1024 of these in cache, there's
a lot of potential for waste.
-> Solve by bounding the growth to 64 at a time. This has similar
characteristics to exponential growth at the default 80x24 terminal
size. May need to add a config option for this step size for users
with very large terminals.
* Lazy eviction from the LFU caches. The underlying cache advisor is
somewhat probabilistic and has a minimum cache size of 256, making
it difficult to maintain low heap utilization.
-> Solve by replacing it with a very simple LFU algorithm. It doesn't
seem to hurt much at the default terminal size with the default
cache sizes. If we make the cache sizes smaller, its overhead is
reduced.
Some further experimentation is needed to adjust defaults, but this
should help reduce heap usage.
refs: https://github.com/wez/wezterm/issues/2626
I noticed from https://github.com/void-linux/void-packages/pull/36903
that 32-bit systems were failing to pass the test suite.
Running `cargo test --target i686-unknown-linux-gnu -- --nocapture
teeny_string` showed that we were faulting in the teenystring code
and digging a bit deeper showed that it was because our assumptions
about the high bits were wrong for 32-bit systems.
Fix this by making TeenyString based around a u64 rather than usize
so that we guarantee its size on all current systems.
We weren't including the invisible space cells into the model
as part of building up the logical line, resulting in the logical
line being shorter than it should have been.
That resulted in some of the components of the double wide cells
not being rendered in the correct place.
refs: https://github.com/wez/wezterm/issues/2571
refs: https://github.com/wez/wezterm/issues/2568
When in raw mode, go to level 2, but use level 1 for cooked
so that we don't obfuscate ctrl-c.
A consequnce of this is that CTRL-C is now reported to the app
as CTRL-lowercase-c where we previously reported as CTRL-uppercase-C.
Made a note of the breaking nature of this change in a new changelog
file.
Fixed recognizing SHIFT-TAB
refs: https://github.com/wez/wezterm/issues/2511
With a TERM of "screen-256color" or "screen", common attributes such
as bold are rendered with a \x0f AKA ^O AKA \017 code that
makes pagers such as less and streampager grumpy. In particular,
streampager renders as inverted "<0F>" and less as inverted "^O".
Add a new flag force_terminfo_render_to_use_ansi_sgr which makes the
TerminfoRenderer ignore the terminfo entries for common attributes,
instead using the standard ANSI/ECMA-48 sequences.
I've expanded the number of bits from 16->32 without impacting
the overall struct sizes and reserved 2 bits for super/subscript.
I refer to these as vertical alignment properties for conceptual
consistency with css.
SGR 73, 74, 75 are used to set super, sub and normal vertical alignment.
These are compatible with mintty.
However, mintty just added support for setting both attributes to render in
small caps in 06ac446049
(https://github.com/mintty/mintty/issues/1171)
According to its benchmarks, it's almost 2x faster than
unicode_segmentation. It doesn't appear to make a visible
difference to `time cat bigfile`, but I'll take anything
that gives more headroom for such little effort of switching.
Action is used to encode parsed terminal output and shuttle it between
the thread that does the parsing and the main gui thread that applies
it to the terminal model.
Take it down from 184 bytes to 40 bytes (on 64-bit systems). This seems
to boost `time cat bigfile` by reducing the runtime to ~40% of its prior
duration: down from 8s -> 4.5s on an M1 macbook air.
Size reductions achieved by Box'ing relatively less frequently
used enum variants. The kitty image data variant is particularly
large, and the Window variant is also pretty heavy.
There were two problems:
* We weren't correctly invalidating when the hover state changed
(a recent regression caused by recent caching changes)
* We'd underline every link with the same destination on hover,
not just the one under the mouse (longstanding wart)
Recent changes allow the application layer to reference the underlying
Lines directly, so we can restore the original and expected
only-highlight-under-the-mouse by switching to those newer APIs.
Adjust the cache values so that we know to also verify the current
highlight and invalidate.
I was a little surprised to see that this also works with mux client
panes: I was expecting to need to do some follow up on those because
they return copies of Line rather than references to them. That happens
to work because the mux client updates the hyperlinks at the time where
it inserts into its cache. The effect of that is that lines in mux
client panes won't update to new hyperlink rules if they were received
prior to a change in the config.
refs: https://github.com/wez/wezterm/issues/2496
Given this sequence:
ENABLE-UNDERLINE CRLF SGR-RESET
if the CRLF caused the terminal to scroll, the newly created line
at the bottom would be filled in with a "blank" cell that had
the underline attribute set.
That's because we're supposed to preserve the coloring in that
scenario, but we were also preserving other SGR attributes.
This commit explicitly clears out under, over and strikethrough
lines from these blank attributes.
refs: https://github.com/wez/wezterm/issues/2489
Move is_double_wide to a box; it is relatively rare to need
this and we're okay with it being a separate heap allocation
when it is needed if it reduces the size of Line in the common case.
I don't think these are really necessary any more; the implementation
cannot go out of bounds, so the worst that can happen is that we
don't return any changes.
refs: https://github.com/wez/wezterm/issues/2222
