We need access to the underlying raw/physical key in order
to correctly encode in some modes, so we need the full KeyEvent
struct for that.
Move the encoder up so it sits alongside the win32 input mode
encoder.
This should give us better results for both shifted/unshifted
and the "base layout" (US english) representations of a number
of keys.
Note that this is still not 100% technically correct: the unshifted
keys require knowledge of the keyboard layout that we don't have
at this OS-independent layer.
Right now we're assuming a US layout to unshift punctuation, which
is not right if you're not using that layout. To resolve that,
more work is needed on each OS to be able to extract that information
and then to store it in the KeyEvent.
refs: https://github.com/wez/wezterm/issues/3479
refs: https://github.com/wez/wezterm/issues/2546
We were missing encoding of these for the base xterm encoding
(I haven't daily driven a keyboard with a numpad in over 10 years!).
Improve mapping for the kitty protocol.
refs: https://github.com/wez/wezterm/issues/3478
This commit teaches the termwiz layer about positional modifiers,
and expands our modifier concept to also pass through led states
such as caps lock and num lock.
Those aren't actually keyboard modifiers, but the state is useful
to recognize.
Adjust the shift key normalization so that we don't uppercase
alpha characters when both SHIFT and CAPS_LOCK are held.
This processing will remove both SHIFT and CAPS_LOCK in that
situation.
Add a method to KeyEvent that will undo the OS keyboard layer
normalization of positional to generic modifier key presses.
eg: the OS may map LeftControl -> Control, but we actually
prefer to have LeftControl so if we can unambiguously reverse
that mapping, we do so.
refs: #3476
refs: #3475
- v2.0 no longer derives a bunch of traits (Debug, Clone, Copy, PartialEq, Eq)
by default, so I manually derived them.
- It also changed the snapshot results so I updated them:
An empty bitflags struct is no longer displayed as `None` but as
`BitFlags(0x0)`.
- `bits` is no longer a field but a method so I added the missing
parenthesis.
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
Nudge new users towards using this style:
```lua
local config = {}
config.color_scheme = 'Batman'
return config
```
and surface how to write lua modules closer to the main section
on config files. In that lua modules section, nudge towards using
a convention similar to that of the plugin spec described in
this commit: e4ae8a844d
Adopt the new blob lease layer to storing and referencing
image files.
This reduces the number of open files needed when
images are being displayed in the terminal.
refs: https://github.com/wez/wezterm/issues/3263
Input data:
\e_Ga=T,f=32,s=10,v=22,c=1,r=1,m=1\e\\e_Gm=1;/xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T//P=\e\\e_Gm=1;/xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T////E////xP///8T//P=\e\\e_Gm=0\e\
There were two issues in handling this:
* We expected there to be `;payload` in the first transmission packet,
but there wasn't one, so we ignored it as ill-formed.
* The standard base64 decoder in the rust ecosystem is super strict
and rejects the "sloppy" python base64 encoder output that isn't
strictly conformant with the RFC. We need to jump through some
hoops to get it to relax and accept the input.
refs: https://github.com/wez/wezterm/issues/2716
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.
