Now we can optionally skip loading svg fonts, making our default
to continue to try to use them.
We don't actually support interpreting svg data, but we do now
support COLR v1 data which is found in some of those same fonts.
refs: https://github.com/wez/wezterm/issues/4148
The harfbuzz driven rasterization of COLR glyphs is superior to
my attept at a freetype driven rasterizer, so let's default to
the harfbuzz version.
This change means that the default for most regular glyphs is
freetype, but we'll use harfbuzz for COLR glyphs.
Popping open the char selector could result in comedy-sized emoji
that dramatically overflow the bounds.
The reason for that is that glyphcache isn't smart enough to notice
when the glyph.height exceeds the cell_height and allows the glyph
bitmap to be rendered at the rasterized size.
The reason for that glyph being so huge is that freetype is producing
outlines that are too large. The font metrics have the requested
x and y ppem values (eg: the nominal font size in pixels), but also
x and y scaling values that are not set to 1. The result is that
the produced extents are too large by those x and y scaling values.
I'm not sure why that is, but it is simplest and most self-contained
to adjust for that scale factor when we rasterize via cairo, so that
is what we do here.
When using the harfbuzz rasterizer with a bitmap glyph, the result
is a rasterized glyph that is pre-scaled to the cell dimensions.
We need to tell glyphcache that that has happened, otherwise it
will apply the same scale factor again.
I think I've got the right values going in and out, so I think
it's ok to turn this on, but I'm worried about legacy non-opentype
formats that freetype supports but harfbuzz doesn't.
Let's stick with ft's metrics until I find time to validate
the behavior.
This isn't fully baked, but it looks mostly ok.
The ghost emoji has a weirdly positioned white patch; there's
something funky with its positioning that needs to be investigated.
There's some copypasta here; a bunch of the cairo related stuff
was copied and adapted from the harfbuzz impl.
I plan to refactor the latter in terms of the former to reduce
the amount of code overall.
fixup colors and excessive clipping.
This now looks decent. Still don't support sweep gradients;
those look complex and I'm not sure that I have a font to
test that against.
This meshes well with the sequence of instructions that we
get from harfbuzz.
This will need some vendoring to integrate with wezterm's build
on all platforms; that can come later.
Still need to hook up gradients.
We need to make a couple of passes over the paint instructions,
and making a nice interface around FontFuncs and DrawFuncs was
taking up a lot of boilerplate.
Adjust so that we accumulate parsed PaintOps and DrawOps instead.
This makes the code smaller and easier to grok.
Still has trouble rasterizing the new noto color emoji font though.
I think this fixes up the discrepancy I had in metrics with images.
The "solution" is to tell harfbuzz to scale to the selected
bitmap strike size instead of the the computed pixel size for
the current settings.
I'm experimenting with using cairo's 2D graphics for glyph related
drawing operations, and perhaps more stuff in the UI in the future.
The challenge is that no one has yet encapsulated its build in a
cargo-friendly way.
This commit is that attempt.
The strategy is this:
* `deps/cairo` is ostensibly the same thing as https://github.com/gtk-rs/gtk-rs-core/tree/master/cairo/sys
which is the cairo-sys-rs crate
* Its build.rs has been replaced with a version that builds from the C
sources that are found in-tree; it will never look for the system
cairo library
* A pair of scripts to import pixman (a required dep of cairo) and
cairo itself in a repeatable way are include, for if/when we need
to update the vendored sources
Cairo is a mature library and doesn't release very often.
* The workspace sets a patch for crates.io so that cairo-rs has
its cairo-sys-rs dep redirected to the local build.
I'm not planning to upstream this stuff to gtk-rs-core as full cairo
depends on a lot more things than are dealt with here, so it would be a
PITA to handle that generally.
This vendoring strips out things that are not used, so the cairo
library that remains:
* Is not internally thread safe; no TLS or mutex support is enabled
in either of them. That's fine because the high level cairo-rs
wrapper is not Send+Sync, which means that rust will only allow
it to be used single threaded anyway.
* Only has the basic recording and image surfaces
* No platform support for win32/xlib/xcb and so on
The vertical alignment is wonky, and some glyphs have the wrong
aspect and are missig colors. eg: the watermelon glyph in Noto Color
Emoji (U+1f349).
Turn this off by default, and skip loading fonts that have svg by
default.
The approach we were using previously was to ask macOS for the fallback
font list, but it didn't include the correct fonts for certain
codepoints.
Switch to using an alternative API that asks macOS which font to use for
a specific codepoint.
refs: #4099
- Removes closures and function calls for types that implement default:
```rust
// Change
let _my_str = get_str().unwrap_or(String::new);
// To
let _my_str = get_str().unwrap_or_default();
```
- Uses the `.cloned()/.copied()` methods where possible
- Use function pointer instead of simple closure
May improve performace, as closures generate more code, and this might
unlock some inlining opportunities.
- Use `find` instead of `position(..).next()`
- Use `any` instead of `position(..).next().is_some()/.is_none()`
- Use `first/next` instead of `get(0)/nth(0)`
- Prefer `for` loops over `while let` loops on iterators
May improve performance.
In https://github.com/wez/wezterm/issues/2932 the user desired to have
brightened text without the boldness, as they were accustomed to that
behavior in a couple of other terminal emulators.
This commit changes the `bold_brightens_ansi_colors` from a simple
boolean to a tristate that allows for not changing the brightness,
changing the brightness, and changing the brightness while adjusting
the boldness down to normal levels.
boolean values are accepted for backwards compatibility.
This commit introduces a rough first pass at a command palette modal.
It is an adaptation of the emoji character selector and needs
refinement.
Importantly, the default pane selector key assignment now calls
into this new command palette instead.
refs: https://github.com/wez/wezterm/issues/1485
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.
This sequence forms a grapheme with cell_width=2, but harfbuzz returns
it as two distinct clusters, causing our prior logic to shape them
independently from different fonts, but our logic for assessing width
would resolve them both to the same cell and double-count their width,
leading to issues with the rendered result.
This commit revises our clustering logic to add a pass that compares
the harfbuzz cluster positions with the cell-based positions from
the presentation_width that may have been provided. We use the starting
cell positions from that to order and de-dup so that clusters aren't
split in the wrong place.
refs: https://github.com/wez/wezterm/issues/2572
I was going to upgrade to the unicode 15 font, but in testing this I
decided that the logic is slightly complex and the glyphs are often
difficult to see at most terminal font sizes, which generates questions
from users, so just fall back to notdef.
The clustered line storage impl of get_cell() is O(column-index)
as cells have to be iterated in order.
The render pass was calling it 3 times to resolve information
about the cursor; reduce that to just once.
It was also calling it once per cell to determine whether the
cell needed to be replaced with a custom glyph if custom block
glyphs were enabled, making it accidentally quadratic!
While it wasn't especially expensive, it did show up in profiling,
so this commit removes that call: we can cache the block glyph
key in the shaper info which is a better place for it anyway,
so that's what we do.
Similarly, there was some extraneous work to call get_cell
when computing some shaper info; remove that too!
That one might be slightly contentious: the is-followed-by-space
logic used to check the successor cell by index to see if it
was a space, but now looks at the successor shaped glyph to see
if it was a space. That might actually be a better choice, but
it may have some ripple effects.
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.
