If shaping can't resolve some glyphs, queue the font locator
fallback resolution to another thread; meanwhile, a last resort
glyph is used.
That thread can trigger an invalidation once the fallback resolve
is complete, the window is invalidated and the last resort glyph
is replaced by the resolve glyph.
refs: https://github.com/wez/wezterm/issues/559
refs: https://github.com/wez/wezterm/issues/508
Keep track of the glyphs we've already advised about (until the
config is reloaded) so that we don't keep spamming the user.
refs: https://github.com/wez/wezterm/issues/559
* Check built-in fonts before asking the system for codepoint coverage
* If one of the earlier stages resolved some fonts, skip the remaining
stages and speculatively shape what we have. This avoids triggering
the system font lookup for fonts that are present in the font_dirs
or that are built-in, such as powerline symbols.
refs: https://github.com/wez/wezterm/issues/559
Default `allow_square_glyphs_to_overflow_width="WhenFollowedBySpace"`,
and expand its meaning from mostly square glyphs to glyphs that are
also wider than they are tall.
refs: https://github.com/wez/wezterm/issues/565
There's something fishy with colorspaces and blending.
This commit removes the `window::Color` type and replaces
it and the confusing array of color types exposed by the
`palette` crate with a pair of much simpler types:
`LinearRgb` - a tuple of f32 linear color components
`SrgbaPixel` - the u32 sRGBA pixel representation
This doesn't change anything about rendering, it just
makes it a bit simpler and makes the SrgbaPixel -> LinearRgb
conversion happen slightly earlier which shaves off some
ad-hoc conversions.
Refs: https://github.com/wez/wezterm/issues/544
hoist the underlyine glyph retrieval out of the loop.
Precompute some color conversions (less effective until
the gamma branch is merged).
refs: https://github.com/wez/wezterm/issues/546
Switches from using a dynamic vertex buffer to an immutable
vertex buffer. This feels counter-intuitive to me; the purpose
of dynamic is to sustain frequent updates, but mapping the buffer
needs to synchronize with the GPU, and if we are rapidly invalidating
the window that can stall painting by tens of milliseconds.
Switching to an immutable buffer avoids the stall and makes
quad mapping more consistently < 10ms, but its still not
ideal.
refs: https://github.com/wez/wezterm/issues/546
* Make window invalidation more efficient by avoiding spawning a call
that spawns a call to invalidate the window. Just directly mark as
invalidated.
* Suppress default background erase
* hoist the bg_color calc for quads that don't have Cells outside of
its loop.
refs: https://github.com/wez/wezterm/issues/546
The dwrote crate offers functions that can extract the underlying
font file name(s) from the system, so let's use those to get
OnDisk font handles and save some memory.
refs: https://github.com/wez/wezterm/issues/559
I'm not sure what exactly changed (perhaps it was a Windows updated?)
but window_background_opacity was only taking effect for windows
with no title bar.
I found that explicitly configuring a region makes transparency
work again.
refs: #553
In an earlier incarnation of both wezterm and freetype, FT_New_Face
would lead file descriptors into child processes because it didn't
set O_CLOEXEC. That led to the slightly pessimistic approach of
loading the font into memory for the lifetime of the wezterm process.
With the improved fallback handling on macos, this can result in
hundreds of MB of font data being loaded, in some cases multiple
times.
Since those days, freetype now sets O_CLOEXEC and wezterm has some
logic to close other random fds, so the descriptor leaking problem
is gone and we can now let freetype manage a file handle instead
of a memory-baked font.
This reduces the memory utilization by at least 1GB in the case
that a glyphs need to be resolved from the system fallback fonts.
refs: https://github.com/wez/wezterm/issues/559
terminus-bold.otb reports 0 height!
Detect and force that case to go through the bitmap strike loading
code path.
Improve the size selection heuristic for bitmap strikes: previously,
we would just pick the largest bitmap and allow it to be scaled down,
which was OK for emoji fonts that just had 128px square glyphs, but
is not ok for pre-rendered pixel strikes like terminus.
Note that IncreaseFontSize works in terms of percentages only,
so using a font like this may have "gaps" when ctrl-+ or - to change
the font size.
refs: https://github.com/wez/wezterm/issues/560
I don't understand how fish ends up blocking forever in the related
issue, but it shouldn't block us too! The price of this situation
is likely a lingering zombie child process but that seems fine.
refs: https://github.com/wez/wezterm/issues/558
I've had a few people comment that the screen repaints stutter
more since the most recent release.
One of the main changes in that area was to increase throughput
for timg case, where a lot of data was being pumped through.
I think that, ironically, the decreased latency results in more
frequent repaints where not all of the updated screen is visible
in a full screen redraw, so it appears more janky.
This commit introduces a small 1ms delay to see if additional
output is forthcoming when parsing the data. It will keep
delaying and accumulating until there's at least one parsed
output action to process, so there is a small constant latency
overhead added to a single character output (thread context
switch + 1ms delay).
This small delay is counter-balanced with raising the priority
of dispatching the render actions; previously we'd spawn them
at lower-than-input priority. With the batching potential,
I think spawning them at the same priority is OK; the main
reason for the lower priority was to ensure timely ctrl-c
processing when a lot of output is being dumped to the terminal.
It's hard for me to gauge whether this fixes the reported issue,
as I've been unable to reproduce it for myself.
refs: https://github.com/wez/wezterm/issues/559
refs: https://github.com/wez/wezterm/issues/546
I didn't realize that xterm inherited some additional mappings from
the X server, so this commit should make us more comformant with
xterms behavior.
Verified this by comparing `showkey -a` under both xterm and wezterm:
```
wezterm -n --config disable_default_key_bindings=true --config debug_key_events=true start -- showkey -a
```
refs: https://github.com/wez/wezterm/issues/236
refs: https://github.com/wez/wezterm/discussions/556
This is a bit unfortunate, but necessary, because the system fallback
list contains a handful of special fonts that apple doesn't ship on
disk in ttf/otf files.
One of those is `.AppleSymbolsFB` which would normally satisfy
the symbol lookup.
This commit hard codes the "Apple Symbols" font to use instead,
which is a disk based font. I don't know what the difference
is between it and `.AppleSymbolsFB`, but this is sufficient
to satisfy the glyph in question from the referenced issue.
refs: https://github.com/wez/wezterm/issues/506
CI got broken by the termwiz release. This commit teaches the
various `git describe --tags` calls to filter to the wezterm
tags which all start with the year. We're match `20*` which should
be good for the next 79 years.
I've removed the vergen dependency as there was no way to teach it
to do the equivalent matching, and it wasn't a terrible burden
to just inline the git describe call anyway.
I'm not convinced that this is 100% good, but @fanzeyi reported
some latency when using tmux to mirror two sessions. The session
that was accepting interactive input responded quickly, but the
mirroring session was laggy.
This change connects the mux pane output event to window invalidation,
which should cause repaints to happen more often.
I couldn't reproduce the scenario above on my M1 mac, but that may
just be because M1 has dark magicks.
