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.
Need to use a newer version of libssh-rs that can report this state,
as the underlying libssh doesn't fold it into the process exit
status.
refs: https://github.com/wez/wezterm/issues/3095
A user reported this:
08:47:13.372 DEBUG window::os::x11::connection > Unable to
resolve appearance using xdg-desktop-portal: Read:
org.freedesktop.DBus.Error.TimedOut: Failed to activate service
'org.freedesktop.portal.Desktop': timed out
(service_start_timeout=120000ms)
which is an issue with their xdg-portal service.
Rather than have wezterm block for 2 minutes on startup, we give it
1 second, and log the issue as a warning.
Brief usage notes here:
```lua
local wezterm = require 'wezterm'
local a_plugin = wezterm.plugin.require "https://github.com/owner/repo"
local config = wezterm.config_builder()
a_plugin.apply_to_config(config)
return config
```
The referenced repo is expected to have a `plugin/init.lua` file,
and by convention, return a module that exports an `apply_to_config`
function that accepts at least a config builder parameter, but may
pass other parameters, or a lua table with a `config` field that maps
to a config build parameter.
`wezterm.plugin.require` will clone the repo if it doesn't already
exist and store it in the runtime dir under `plugins/NAME` where
`NAME` is derived from the repo URL. Once cloned, the repo is
NOT automatically updated.
Only HTTP (or local filesystem) repos are allowed for the git URL;
we cannot currently use ssh for this due to conflicting version
requirements that I'll take a look at later.
`wezterm.plugin.require` will then perform `require "NAME"`,
and since the default `package.path` now includes the appropriate
location from the runtime dir, the module should load.
Two other functions are available:
`wezterm.plugin.list()` will list the plugin repos.
`wezterm.plugin.update_all()` will attempt to fast-forward or `pull
--rebase` each of the repos it finds. It doesn't currently do anything
proactive to reload the configuration afterwards; the user will need to
do that themselves.
Avoids:
```
warning: the following packages contain code that will be rejected by a future version of Rust: ntapi v0.3.7
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 36`
```
This is a step towards making it Send+Sync.
I'm a little cagey about this in the long term, as there are some mux
operations that may technically require multiple fields to be locked for
their duration: allowing free-threaded access may introduce some subtle
(or not so subtle!) interleaving conditions where the overall mux state
is not yet consistent.
I'm thinking of prune_dead_windows kicking in while the mux is in the
middle of being manipulated.
I did try an initial pass of just moving everything under one lock, but
there is already quite a lot of mixed read/write access to different
aspects of the mux.
We'll see what bubbles up later!
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.
We were only using block_on from it, which we can call from the
underlying async_io crate.
Notably, removing async_std from the deps avoids async-global-executor
being pulled in and spawning nproc threads that are never used by
wezterm.
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.
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.
There are caveats to determining this, but when we think
password entry is enabled, switch the cursor to the font-awesome
lock glyph instead of the normal cursor sprite.
fa_lock is used because it is monochrome and can thus be tinted
to the configured cursor color, and it respects blinking/easing.
refs: https://github.com/wez/wezterm/issues/2460
The idea here is that different kinds of panes may want to expose
additional metadata to lua scripts. It would be a bit weird to add
a Pane method for each of those and plumb it all the way through
the various APIs, so just allowing a pane impl to return a dynamic
value (likely an Object) allows a bunch of flexibility.
This commit exposes the clientpane is_tardy boolean and the time
since the last data was recevied (since_last_response_ms) from
the mux client pane implementation: these are used to show the
tardiness indicator in the client pane.
Exposing this data enables the user to add that info to their
status bar if they wish.
CTRL-SHIFT-U is a new default key assignment for this new modal.
It opens up a fuzzy searchable browser that defaults to showing
emoji/emoticons. The category can by cycled through the suggested
emoji categories using CTRL-r. Unlike the system emoji palette,
wezterm includes a category for nerdfont symbols, and another
that is a list of all unicode codepoint names, so you should be
able to browse for pretty much any codepoint you can think of.
The modal also allows fuzzy searching based on:
* The official unicode name
* The github shortcode
* codepoint value in hex
so if you know the codepoint value but not the name, you can
still find a way to input what you're looking for.
Pressing Enter will copy the selected item to the clipboard
send it to the active pane, and cancel the modal. You can therefore
repeat the insert by simply pasting.
I plan to add frecency to this in a later commit: that way the
frequently/recently used selections will show in a category of
their own and make it easier to re-input them.
refs: https://github.com/wez/wezterm/issues/2163
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.
The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.
I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.
refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
`wezterm start -- /etc/profile` would crash on macOS because
`/etc/profile` isn't executable.
This commit checks for executable access as a prereq for both the
path search and the absolute path cases and generates a non-crashing
error:
```
$ wezterm start -- /etc/profile
17:24:03.574 ERROR wezterm_gui > Unable to spawn /etc/profile because it doesn't exist on the filesystem or is not executable (EACCES: Permission denied); terminating
```
