- If possible use fontconfig to obtain character coverage instead of
going through all glyphs using freetype.
- `FT_Get_First_Char` typically returns ranges of continuous glyphs itself
and it is far cheaper (I measured a speedup of about 7 times while
catting a large file with lots of funny unicode) to add a range to the
glyph coverage instead of adding each glyph individually.
- Permit adding a range to a RangeSet without performing checks to speed
up things even further.
@H-M-H noticed and suggested this; rather than spawning a thread
for potentially every cluster of graphemes that are being displayed
before we've located a font, constrain things to a single thread
so that we don't burn CPU trying to process the same results
in an excessive number of threads.
I think this is a hangover from the older logic to figure out
the initial sizing, and I suspect that it is what is causing
refs: 1074
So this is a speculative change to see if it helps!
Since fonts now use dual source blending, the pixel colors are
interpreted as individual alpha channels. The A component should
be set to 1.0, so that's what we do here.
refs: #1025
I noticed while reviewing the session recording for https://github.com/wez/wezterm/issues/1102
that wezterm reported:
```
2021-09-04T22:05:46.136Z WARN wezterm_term::terminalstate::performer > unknown unspecified CSI: "58::2::87::61::38m"
2021-09-04T22:05:46.138Z WARN wezterm_term::terminalstate::performer > unknown unspecified CSI: "58::2::87::61::38m"
```
Those extra double-colons aren't valid, and I think they're coming from
this terminfo file, so fix it up!
This will enable eg: a lua helper function to serialize keycodes to
assist in some key rebinding scenarios (see:
https://github.com/wez/wezterm/pull/1091#issuecomment-910940833 for the
gist of it) but also makes it a bit easier to write unit tests for key
encoding so that situations like those in #892 are potentially less
likely to occur in the future.
Not sure what happened here: presumably a borked merge or something
similar, but this commit allows `window:get_appearance` to return
the actual appearance value on X11.
Even though this plumbs the call through to Wayland, Wayland doesn't
provide an equivalent concept so still always return Light, as is
mentioned on our docs.
closes: #1098
* Trigger a paint immediately from invalidate if not throttled
* Otherwise defer the other events until we're about to sleep for xcb
events, which should maximize the coalesce around resize/expose events
refs: #1051
The thesis is that some WM's might send a whole bunch of events
that cause us to over draw/over resize.
I'm not convinced that this is a righteous change, but it can't
hurt to try.
refs: #1051
This splits rendering into 3 passes:
* background pass for z-index < 0. This is for solid background colors,
background images, and image attachments with z-index < 0.
Rendered with regular alpha blending.
* glyph pass: for glyphs at z-index==0. This is rendered with dual
source blending enabled to facilitate subpixel aa appearance.
* top layer pass for z-index >= 0 graphics. This is rendered with
regular alpha blending.
This avoids weird effects, like images with alpha shining through
the back of the window when the window itself isn't transparent.
refs: #544
