* Update macos docs with wezterm CLI installation
wezterm binary is not by default available in shells like the default zsh or bash, on macos we need to explicitly add the path to the wezterm binaries inside the WezTerm.app
* Update docs/install/macos.markdown
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
Using the new abstractions, we can call into webgpu code now.
It doesn't do anything useful, and in fact crashes because
the mapping of the quads is doing the wrong thing.
Will fix in the next commit.
The recent changes to clustering make this more likely to happen.
This doesn't handle overflow resulting from changing styles in the tab
title, but those are less common.
refs: https://github.com/wez/wezterm/issues/2560
Since we're no longer tied to contiguous Vertex slices, we can
record the Quad data used for HeapQuadAllocator in a smaller structure,
so that's what this does.
It reduces the per-Quad storage from 272 bytes down to 84 bytes,
which helps with overall memory usage: the default cache size is 1024
lines worth of quads, so this can add up to multiple MB of RAM.
refs: https://github.com/wez/wezterm/issues/2626
This reduces peak heap usage by several MB by making better use
of allocated memory--no wasted overhead in the Vec capacity.
refs: https://github.com/wez/wezterm/issues/2626
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
Do it "more properly": use intrusive list linkage to manage three
indices:
* hash lookup
* recency
* frequency
eviction is frequency based, but in order to avoid things that were
super hot in the past and that are no longer hot clogging up the cache,
eviction will incrementally age out least recently used entries that
haven't been active in the span of some number of get/put operations.
Aging scales down the frequency value to reduce its strength, so an aged
item isn't necessarily immediately a candidate for removal, it just
makes it more likely to be picked up by the frequency based removal as
it goes unused for an extended period.
