Fix for Issue #12940
I actually do not know if this has already been resolved and the issue
is just still open. Either way, here's a fix. Now we run a check to see
if the current program is accepting mouse events before discarding the
middle click.
Fixes#13386, based on
https://github.com/mustafa0x/ghostty/commit/a8c090
Defer transparent-titlebar KVO rebinding to the next main-queue turn.
Track the observed tab group so unchanged bindings are preserved.
Previously, a tab-group callback could invalidate and recreate its own
observation before returning, leaving closed terminal windows registered
with AppKit after the undo timeout. These windows accumulated titlebar
and layer state, increasing memory use and WindowServer CPU with tab
churn.
Validated with an AppDelegate change that sat and created/closed tabs in
a loop, then counted weak controllers/windows/nsapp window.
Most obvious next step in translating Ghostty is the command palette.
Added support for i18n.N_ (https://docs.gtk.org/glib/i18n.html#macros).
Made a Latvian translation for the command palette to test. Codex did
bulk of the translations but I verified them.
Fixes#13386
Defer transparent-titlebar KVO rebinding to the next main-queue turn.
Track the observed tab group so unchanged bindings are preserved.
Previously, a tab-group callback could invalidate and recreate its own
observation before returning, leaving closed terminal windows registered
with AppKit after the undo timeout. These windows accumulated titlebar and
layer state, increasing memory use and WindowServer CPU with tab churn.
Validated with an AppDelegate change that sat and created/closed tabs
in a loop, then counted weak controllers/windows/nsapp window.
Co-authored-by: Mustafa J <mustafa.0x@gmail.com>
the original wording is a bit confusing; I thought cursor-click-to-move
required shell-integration to be enabled, and was confused when the
mouse was still moving my cursor in fish even with
shell-integration=none.
#11799
Creating a CGEventTap without Accessibility permission leaks a Mach port
inside CoreGraphics on every failed attempt. The global keybind listener
retried this once per second while waiting for permission, so Ghostty
eventually exhausted the process port limit.
Request Accessibility access once, poll AXIsProcessTrusted while access
is denied, and create the event tap only after access is granted. Stop
polling before creation so an unrelated tap failure cannot restart the
leaking retry loop.
Tested this with various settings and global keys working fine.
This PR speeds up our formatting (plain text, html, and VT) by anywhere
from ~1.5x to ~8x.
The formatter is the hot path behind multiple features in Ghostty GUI:
clipboard copy (plain/VT/HTML), `write_screen_file`, `selectionString`,
and terminal search sliding window. It's also the hot path for
libghostty users, namely people like
[zmx](https://github.com/neurosnap/zmx) which utilize the VT formatter
to restore a terminal.
This PR also adds the benchmarking infrastructure for the formatter.
## How
- **Fast cell-run optimization.** For simple cells (single codepoint, no
style/hyperlink) we encode them as a single run rather than one at a
time.
- **Make some arguments comptime.** Generates more code but benchmarks
show it improves things, specifically for per-format switches that we do
a LOT.
- **Interned style id fast path.** Styles are interned per page, so id
equality implies style equality. We track the id of the active style and
skip the per-cell `Style` copy + `eql` when it matches.
- **Fast printing.** Avoid `std.fmt` where possible and assemble
integers, RGB colors, codepoints in fixed-width buffers with a single
memcpy. This was extracted partially to `fastprint.zig` so we can reuse
it.
- **Avoid double-formatting for tracked pins.** Previously we formatted
twice (once through a `Discarding` writer to count bytes) for pin maps.
Now I'm smarter about it and do a single pass.
## Performance
All on my machine, 80x24 terminal, 10K lines of scrollback.
| workload | main | this PR | speedup | throughput |
| --------------------- | -------- | -------- | ------- | ---------- |
| plain / plain | 5.74 ms | 1.67 ms | 3.4x | 364 MB/s |
| plain / vt | 6.46 ms | 1.04 ms | 6.2x | 596 MB/s |
| plain / html | 7.39 ms | 2.32 ms | 3.2x | 308 MB/s |
| unicode / plain | 9.74 ms | 5.42 ms | 1.8x | 276 MB/s |
| unicode / vt | 10.42 ms | 5.53 ms | 1.9x | 275 MB/s |
| unicode / html | 12.53 ms | 7.35 ms | 1.7x | 509 MB/s |
| styled / plain | 5.65 ms | 1.69 ms | 3.4x | 360 MB/s |
| styled / vt | 9.07 ms | 4.20 ms | 2.2x | 409 MB/s |
| styled / html | 10.78 ms | 6.64 ms | 1.6x | 740 MB/s |
| mixed / plain | 8.59 ms | 4.81 ms | 1.8x | 226 MB/s |
| mixed / vt | 11.25 ms | 6.65 ms | 1.7x | 250 MB/s |
| mixed / html | 14.47 ms | 10.52 ms | 1.4x | 414 MB/s |
| wrapped / plain | 7.30 ms | 1.11 ms | 6.6x | 733 MB/s |
| wrapped / vt | 8.14 ms | 1.04 ms | 7.8x | 789 MB/s |
| wrapped / html | 9.00 ms | 2.12 ms | 4.2x | 465 MB/s |
| pin-map / plain | 12.51 ms | 3.80 ms | 3.3x | |
| pin-map / vt | 13.12 ms | 2.99 ms | 4.4x | |
| active screen / plain | 12.5 µs | 2.7 µs | 4.6x | |
| active screen / vt | 18.4 µs | 6.8 µs | 2.7x | |
Workloads:
- `plain` is ASCII lines
- `unicode` is 2/3/4-byte codepoints with 10% grapheme clusters
- `styled` is heavy SGR churn
- `mixed` is styles + Unicode + hyperlinks
- `wrapped` is a continuous soft-wrapped stream
- `pin-map`/`active screen` are the selectionString/search-style and
visible-screen-only cases respectively.
Finally, what was previously thought impossible, is now possible.
The blur region itself is far more accurate than what we can conjure up
on our own, and in a much more finetuned and detailed way too.
Thank you, GTK devs!
Closes#13581
#11799
Creating a CGEventTap without Accessibility permission leaks a Mach
port inside CoreGraphics on every failed attempt. The global keybind
listener retried this once per second while waiting for permission, so
Ghostty eventually exhausted the process port limit.
Request Accessibility access once, poll AXIsProcessTrusted while
access is denied, and create the event tap only after access is
granted. Stop polling before creation so an unrelated tap failure
cannot restart the leaking retry loop.
Finally, what was previously thought impossible, is now possible.
The blur region itself is far more accurate than what we can conjure up
on our own, and in a much more finetuned and detailed way too.
Thank you, GTK devs!
GTK 4.23.3 added its own (much smarter) implementation of background blur,
which means our implementation is not only redundant, it also crashes the
program because a surface cannot have multiple associated blur objects.
Ergo, don't do custom blur on newer GTK versions.
See #13578
RunIterator allocated a list of font candidates for every
multi-codepoint grapheme, then scanned it for the first font covering
the entire cluster.
Instead, check the primary and additional font candidates as they're
discovered. This preserves their order while removing the temporary
array and avoids additional lookups when the primary font supports the
full grapheme.
RunIterator allocated a list of font candidates for every multi-codepoint
grapheme, then scanned it for the first font covering the entire cluster.
Instead, check the primary and additional font candidates as they're
discovered. This preserves their order while removing the temporary
array and avoids additional lookups when the primary font supports the
full grapheme.
Represent Kitty image data as a complete/pending tagged union. Kitty
images can now be completed _later_ if we have all their other metadata
up front.
This will be used by the snapshot API to transmit lightweight
information up front so that renderers of the snapshot can show
placeholders and accept mutating pty data, while the real image data
streams in later.
No user-visible behavior changes today.
Messages can own allocated data or a derived config. Some paths (writer
thread draining, mailbox shutdown with unread messages, and queue push
failures) discarded messages without releasing those resources.
This change adds Message.deinit and uses it whenever a message is
discarded.
Represent Kitty image data as a complete/pending tagged union.
Kitty images can now be completed _later_ if we have all their other
metadata up front.
This will be used by the snapshot API to transmit lightweight
information up front so that renderers of the snapshot can show
placeholders and accept mutating pty data, while the real image data
streams in later.
Messages can own allocated data or a derived config. Some paths (writer
thread draining, mailbox shutdown with unread messages, and queue push
failures) discarded messages without releasing those resources.
This change adds Message.deinit and uses it whenever a message is
discarded.
OSC 52 clipboard reads built their response in an allocated buffer and
then passed it through Message.writeReq, which allocated a second copy
for large responses.
Instead, transfer the allocated response directly using .write_alloc.
Small responses now retain their initial allocation until the IO thread
consumes them instead of being copied inline and freed immediately.
Their allocation count is unchanged, while large responses improve from
two allocations to one. Both cases avoid the additional copy.
OSC 52 clipboard reads built their response in an allocated buffer and
then passed it through Message.writeReq, which allocated a second copy
for large responses.
Instead, transfer the allocated response directly using .write_alloc.
Small responses now retain their initial allocation until the IO thread
consumes them instead of being copied inline and freed immediately.
Their allocation count is unchanged, while large responses improve from
two allocations to one. Both cases avoid the additional copy.
This PR improves the way splits/surfaces are sized in the GTK app, which
eliminates flickering and slightly improves performance.
Fixes#13328, #12709, #11187.
Related #8208 (closed) but some later comments mention flickering issues
persisting.
Builds on top of the changes in #12698.
Previously an idle callback was used to sync the split ratio between the
GTK widget tree and the split tree data structure that represents the
split layout. The widget tree contains a `SplitTreeSplit` widget, which
wraps a `GtkPaned` widget, for every split. During size allocation a
`GtkPaned` widget first computes the initial position of the divider and
thereby the size for its two children. We get notified of that position
(and the max possible position) via the `propPosition/propMaxPosition`
callbacks in `SplitTreeSplit` and set up an idle callback (the `onIdle`
function) to update the position if it does not match the desired split
ratio. Since the initial position is often not correct, especially in
nested layouts or if the ratio is not 0.5, a surface will first be shown
with the wrong size for a few frames until the idle callback runs and
corrects the sizing. In nested layouts it might take multiple rounds of
size allocation and idle callbacks until every surface gets the correct
size. This causes flickering as widgets eventually snap to another size,
which is especially noticeable if the layout changes quickly e.g. when
resizing a split using keybinds.
To fix this, the divider position will now be corrected directly from
the `propMaxPosition` callback, which runs during GTK size allocation,
right after a `GtkPaned` computes the initial position and right before
it uses the position to allocate sizes for its two children. With this
change every surface will be sized correctly during the first round of
size allocation.
The idle callback is still used to update the ratio in the split tree
when a split is resized by manually dragging the divider in the UI. The
logic to sync the split ratio was moved to the new `syncSplitRatio`
function which is called from both `propMaxPosition` and `onIdle`.
This is kind of hacky, but I reviewed the GTK source code in detail to
verify that this is safe (see the various code comments for more
details). I also tested extensively on both Hyprland and KDE Plasma:
creating deeply nested layouts, resizing with both keybinds and dragging
dividers by hand, with multiple tabs, resizing the entire window,
resizing entire subtrees to 0 and back. Everything seems to work fine.
For performance testing I used sysprof which can also collect GTK stats.
When creating/deleting/resizing splits I can measure a slight but
consistent increase in GTK FPS (+5 to 10) on my system. Other than that
CPU usage and FPS seem to be the same before and after. I guess this
makes sense, while we added a bit of work to the GTK loop during size
allocation, we avoid surfaces being resized.
For the flickering, here's a side-by-side comparison. Left is before the
changes, right is after.
https://github.com/user-attachments/assets/2a4f0b4b-e113-49b5-b0d7-d9e507a5a4ff
AI Disclosure: no AI was used.
Read-only filtering happens in Surface.queueIo after callers construct
the message. This early return leaked write_alloc payloads because the
IO thread never receives them and therefore does not perform its normal
cleanup.
Read-only filtering happens in Surface.queueIo after callers construct
the message. This early return leaked write_alloc payloads because the
IO thread never receives them and therefore does not perform its normal
cleanup.
This removes use of global state from the crash reporting functionality
(everything in `src/crash`).
This particularly ensures that there are no races on the system
environment during the execution of the initialization thread that would
possibly cause crashes, particularly in any (albeit unsupported) 3rd
party integrations of libghostty-internal.
Ultimately, this pushes any coupling of I/O and environment to places
that would more correctly interface with global state, such as the
same-thread `global.init`, and the crash report CLI.
Note that similar de-coupling actions have been taken on XDG and home
directory functionality, pushing their coupling points up the stack in a
similar way.
