This commit adds a few new mode flags to the `bench-stream` program
to generator synthetic OSC sequences. The new modes are `gen-osc`,
`gen-osc-valid`, and `gen-osc-invalid`. The `gen-osc` mode generates
equal parts valid and invalid OSC sequences, while the suffixed variants
are for generating only valid or invalid sequences, respectively.
This commit also fixes our build system to actually be able to build the
benchmarks. It turns out we were just rebuilding the main Ghostty binary
for `-Demit-bench`. And, our benchmarks didn't run under Zig 0.14, which
is now fixed.
An important new design I'm working towards in this commit is to split
out synthetic data generation to a dedicated package in
`src/bench/synth` although I'm tempted to move it to `src/synth` since
it may be useful outside of benchmarks.
The synth package is a work-in-progress, but it contains a hint of
what's to come. I ultimately want to able to generate all kinds of
synthetic data with a lot of knobs to control dimensionality (e.g. in
the case of OSC sequences: valid/invalid, length, operation types,
etc.).
Fixes#7337
AppKit encodes functional keys as PUA codepoints. We don't want to send
that down as valid text encoding for a key event because KKP uses that
in particular to change the encoding with associated text.
I think there may be a more specific solution to this by only doing this
within the KKP encoding part of KeyEncoder but that was filled with edge
cases and I didn't want to risk breaking anything else.
This allows for `keybind = super+d=new_split` to now work (defaults to
"auto"). This will also let us convert void types to union/enum/struct
types in the future without breaking existing bindings.
Changes:
1. Require `blueprint-compiler` 0.16.0 (or newer) for building from a
git checkout. With #6822 distributions that can't meet that requirement
can use generated source tarballs to build.
2. Remove all `.ui` files as they are unnecessary.
3. Simplify the `Builder` interface since raw `.ui` files are no longer
used.
4. Removed build-time check of raw `.ui` files.
tl;dr: FT_New_Face and FT_Done_Face require the Library to be locked for
thread safety, and FT_Load_Glyph and FT_Render_Glyph and friends need
the face to be locked for thread safety, since we're sharing faces
across threads.
For details see comments and FreeType docs @
-
https://freetype.org/freetype2/docs/reference/ft2-library_setup.html#ft_library
-
https://freetype.org/freetype2/docs/reference/ft2-face_creation.html#ft_face
---
This might resolve the issue discussed in #7016 but I wasn't able to
reliably reproduce it in a way I could debug, so someone who was
experiencing it should probably test this PR.
Additionally I can still semi-reliably produce a crash with the GTK
apprt by setting an `all:` keybind to adjust font sizes and changing the
font size rapidly with many surfaces open with emojis on them.
Unfortunately I can't really tell what the root cause is because the
debug info is broken in QEMU.
However, I do think this is a good idea for us to be thread safe with
this stuff even if it isn't related to that problem.
Prior to #7044, on macOS, our shell integrated command line would be
executed under `exec -l`, which caused bash to be started as a login
shell. Now that we're using direct command execution, add `--login` to
our bash command's arguments on macOS to get that same behavior.
Prior to #7044, on macOS, our shell integrated command line would be
executed under `exec -l`, which caused bash to be started as a login
shell. Now that we're using direct command execution, add `--login` to
our bash command's arguments on macOS to get that same behavior.
