This commit extends the sgr color parser to support a wezterm
extension that I just made up:
```
printf "\e[48:4:255:0:0:60mhello\e0m"
```
The `4` is wezterm specific and denotes 4 channel color, in this case
RGBA. red is 255, green is 0, blue is 0 and alpha is 60; the values are
interpreted as u8 values.
CSI 38 (fg), 48 (bg) and 58 (underline) support this.
refs: https://github.com/wez/wezterm/issues/2313
This doesn't really change any behavior, but adjusts the types
such that CSIs that set colors have the potential to track the
alpha channel and that can make it through to the GUI/render layer.
Just clamp it to the current physical, non-scrollback portion
of the screen.
This avoids a panic but doesn't address the screen size mismatch
in the associated issue.
refs: https://github.com/wez/wezterm/issues/2133
There was a race condition where we could leave the tab
active index pointing to the wrong pane.
That meant that the tab information computed by the gui
layer would see no panes marked as active, and thus would
end up with no active tab.
This commit fixes that by clamping the active index to
the number of panes.
refs: https://github.com/wez/wezterm/issues/2304
The recent work on the scrollback made it easier to constrain the
search region, so expose those parameters to the Pane::search
interface and to the mux protocol.
Use those new parameters to constrain quickselect search to
1000 rows above and below the current viewport by default, and
add a new parameter to QuickSelectArgs that allows overriding that
range.
A follow-up commit could make the search/copy overlay issue a series
of searches in chunks so that it avoids blocking the UI when
searching very large scrollback.
refs: https://github.com/wez/wezterm/pull/1317
In order to avoid searching for "c", "ca", "cat" when typing "cat",
this commit introduces a hard-coded 350ms debounce.
refs: https://github.com/wez/wezterm/issues/1569
If you typed "cat" in the search, the chances are that wezterm
would kick off a search for "c" before you finished typing,
then "ca" and then finally "cat".
There was a race:
clear by_line highlights,
queue search for "c"
clear by_line highlights,
queue search for "ca"
clear by_line highlights,
queue search for "cat"
accumulate highlights for "c" into by_line
accumulate highlights for "ca" into by_line
accumulate highlights for "cat" into by_line
so the final result was a superposition of all of those results,
which was weird!
The fix is simple: clear by_line when we get the results of
an async search.
When adding sparse ranges the cartesian product of range combinations
was explored to find intersections, which is pretty awful if there
are 1 million entries to be inserted.
This commit employs binary search to reduce the complexity, at
the expense of requiring that the internal range array is sorted.
This reduces the resident memory by another ~10% because it avoids
keeping as many runs of whitespace.
Runtime for `time cat enwiki8.wiki` is still ~11-12s, resident: 530K
refs: https://github.com/wez/wezterm/issues/1626
The previous commit added the option to convert the storage to
the cluster format. That saves memory as rows are moved to scrollback,
but makes scrolling back more expensive due to that conversion.
This commit adds a fast(ish) path for the common case of simply
appending text to a new line before it gets scrolled: the default
format for lines in the screen is now the cluster format and,
provided that the cursor moves from left to right as text is
emitted, can simply append to the cluster storage in-place
and avoids a conversion when the line is moved to scrollback.
This improves the throughput of `time cat enwiki8.wiki` so
that the runtime is typically around 11-12s (compared to 9-10s
before introducing cluster storage). However, this is often
a deal of variance in the measured time and I believe that
that is due to the renderer triggering conversions back to
the vec storage and introducing slowdowns from the render side.
That's what I'll investigate next.
This commit causes lines to be "compressed" (really, just translated
to the new clustered line storage variant) as they move into scrollback.
The memory savings are significant for large scrollback:
`wezterm -n --config scrollback_lines=1000000`
`time cat enwiki8.wiki`
before: ~9s, Resident: 2.1G
after: ~15s, Resident: 620K (!)
The performance impact is non-trivial, and I will dig into that
next.
refs: https://github.com/wez/wezterm/issues/1626
Previously this would create a new String because it had to, but
with the clustered storage we may be able to simply reference the
existing string as a str reference, so allow for that.
Adds the option to use an alternative clusted line storage for
the cells component of the line.
This structure is not optimal for mutation, but is better structured
for:
* matching/extracting textual content
* using less memory than the prior simple vector
For some contrast: the line "hello" occupies 5 Cells in the cell based
storage; that 5 discrete Cells each with their own tiny string
and a copy of their attributes.
The clustered version of the line stores one copy of the cell
attributes, the string "hello" and some small (almost constant size)
overhead for some metadata. For simple lines of ascii text, the
clustered version is smaller as there are fewer copies of the cell
attributes. Over the span of a large scrollback and typical terminal
display composition, this saving is anticipated to be significant.
The clustered version is also cheaper to search as it doesn't require
building a copy of the search text for each line (provided the line is
already in clustered form).
This commit introduces the capability: none of the internals request the
new form yet, and there are likely a few call sites that need to be
tweaked to avoid coersion from clustered to vector form.
We didn't actually update the global config, just the per-window
configs, which led to weird stale throwbacks to earlier versions
of the config when spawning windows or new panes.
Fix that up by explicitly reloading the global config when the
window appearance is changed. That isn't ideal as we will reload
once per window, but it's "OK".
While poking at this, I noticed that the get/set config methods
on the termwiztermtab overlay weren't hooked up, and also made
a point of calling those for any overlays during a window config
reload event, so that per-window overrides are more likely to get
picked up and respected.
refs: https://github.com/wez/wezterm/issues/2295
While profiling `time cat bigfile` I noted that a big chunk of the
time is spent computing widths, so I wanted to dig into a bit.
After playing around with a few options, I settled on the approach
in this commit.
The key observations:
* WcWidth::from_char performs a series of binary searches.
The fast path was for ASCII, but anything outside that range
suffered in terms of latency.
* Binary search does a lot more work than a simple table lookup,
so it is desirable to use a lookup, and moreso to combine the
different tables into a single table so that classification
is an O(1) super fast lookup in the most common cases.
Here's some benchmarking results comparing the prior implementation
(grapheme_column_width) against this new pre-computed table
implementation (grapheme_column_width_tbl).
The ASCII case is more than 5x faster than before at a reasonably snappy
~3.5ns, with the more complex cases being closer to a constant ~20ns
down from 120ns in some cases.
There are changes here to widechar_width.rs that should get
upstreamed.
```
column_width ASCII/grapheme_column_width
time: [23.413 ns 23.432 ns 23.451 ns]
column_width ASCII/grapheme_column_width_tbl
time: [3.4066 ns 3.4092 ns 3.4121 ns]
column_width variation selector/grapheme_column_width
time: [119.99 ns 120.13 ns 120.28 ns]
column_width variation selector/grapheme_column_width_tbl
time: [21.185 ns 21.253 ns 21.346 ns]
column_width variation selector unicode 14/grapheme_column_width
time: [119.44 ns 119.56 ns 119.69 ns]
column_width variation selector unicode 14/grapheme_column_width_tbl
time: [21.214 ns 21.236 ns 21.264 ns]
column_width WidenedIn9/grapheme_column_width
time: [99.652 ns 99.905 ns 100.18 ns]
column_width WidenedIn9/grapheme_column_width_tbl
time: [21.394 ns 21.419 ns 21.446 ns]
column_width Unassigned/grapheme_column_width
time: [82.767 ns 82.843 ns 82.926 ns]
column_width Unassigned/grapheme_column_width_tbl
time: [24.230 ns 24.319 ns 24.428 ns]
```
Here's the benchmark summary after cleaning this diff up ready
to commit; it shows ~70-80% improvement in these cases:
```
; cargo criterion -- column_width
column_width ASCII/grapheme_column_width
time: [3.4237 ns 3.4347 ns 3.4463 ns]
change: [-85.401% -85.353% -85.302%] (p = 0.00 < 0.05)
Performance has improved.
column_width variation selector/grapheme_column_width
time: [20.918 ns 20.935 ns 20.957 ns]
change: [-82.562% -82.384% -82.152%] (p = 0.00 < 0.05)
Performance has improved.
column_width variation selector unicode 14/grapheme_column_width
time: [21.190 ns 21.210 ns 21.233 ns]
change: [-82.294% -82.261% -82.224%] (p = 0.00 < 0.05)
Performance has improved.
column_width WidenedIn9/grapheme_column_width
time: [21.603 ns 21.630 ns 21.662 ns]
change: [-78.429% -78.375% -78.322%] (p = 0.00 < 0.05)
Performance has improved.
column_width Unassigned/grapheme_column_width
time: [23.283 ns 23.355 ns 23.435 ns]
change: [-71.826% -71.734% -71.641%] (p = 0.00 < 0.05)
Performance has improved.
```
