Back out "perf(styles): greatly improve style.hash performance" This
backs out commit 3bfe4cd25ca7a5ae4d4084818b86ada9236b3bb5, but keeps the
hash algorithm as XxHash3 which showed improvements in performance.
Back out "perf(styles): greatly improve style.hash performance"
This backs out commit 3bfe4cd25ca7a5ae4d4084818b86ada9236b3bb5, but
keeps the hash algorithm as XxHash3 which showed improvements in
performance.
To preface, I tested the impact of these changes by running
DOOM-fire-zig in a 120x30 window on a ReleaseFast build. I feel that
DOOM-fire-zig is a fairly realistic target when it comes to "high style
use" terminal applications.
1. By adjusting the conditions under which we swap items while inserting
in to our hash table in `RefCountedSet` we can prioritize styles with
many refs, so they're more likely to stay near their target bucket. This
change brought DFZ FPS from ~700 to ~840, or a roughly 20% improvement.
2. By changing how we hash `Style` structs, we can avoid a lot of
unnecessary overhead and benefit from smaller i-cache size as well as
xxHash's better statistical qualities when compared to Wyhash. This
change brought DFZ FPS from ~840 to ~1020, or another roughly 20%
improvement.
These two changes combined represent as roughly 45% improvement over
`main`, which is... pretty good I'd say.
In addition, I've run `vtebench` and there is no significant difference
in the results between this PR and main.
By switching to one-shot hashing of the raw bytes of the struct with
XxHash3 instead of using `autoHash` with Wyhash, a performance gain of
around 20% can be observed in DOOM-fire-zig.
Fixes#2841
We were incorrectly applying the start/end x offset for the first/last
row of every single page. If a selection spanned multiple pages this
would trim data incorrectly.
Unit test updated to cover this case.
Fixes#2841
We were incorrectly applying the start/end x offset for the first/last
row of every single page. If a selection spanned multiple pages this
would trim data incorrectly.
Unit test updated to cover this case.
Fixes#2332
Two bugs fixed to fix this behavior:
1. Our destination height didn't account for the top-left being
offscreen.
2. We were using the wrong height for the source rectangle. When a rows
param (r=) is specified, the image height and destination height are at
different scales. We were using the viewport scale for the offset but it
should be the image scale.
Fixes#2332
Two bugs fixed to fix this behavior:
1. Our destination height didn't account for the top-left being
offscreen.
2. We were using the wrong height for the source rectangle. When a rows
param (r=) is specified, the image height and destination height are
at different scales. We were using the viewport scale for the offset
but it should be the image scale.
Fixes#2497
While investigating the issue I added an integrity check that found a
problem hiding in the insert logic that was unrelated- in fixing that I
greatly simplified the insert logic.
It turns out that #2497 is ultimately just a case of bad luck,
pathological inputs that result in very non-uniform hashes so the
clustering overwhelms things. The solution was just to add a check and
claim we're out of memory.
I tried adding an entropy folding function to fix the hash a little but
it had a measurable negative impact on performance and isn't necessary
so I've not included it here. Currently there's an open PR to Zig to
[add RapidHash](https://github.com/ziglang/zig/pull/22085), which is the
successor to Wyhash and apparently has much better statistical
characteristics on top of being faster. I imagine it will land in time
for 0.14 so whenever we update to 0.14 we should probably switch our
standard hash function to RapidHash, which I imagine should yield
improvements across the board.
Using the AutoHasher may also be not the best idea, I may explore ways
to improve how we generate our style hashes in the future.
According to the GNOME human interface guidelines, buttons for the main
user actions, such as new, add, open, and back should be placed at the
start of the header bar.
(https://developer.gnome.org/hig/patterns/containers/header-bars.html#header-bar-buttons)
Moving the new tab button to the start of the header bar brings Ghostty
in line with other GNOME applications such as gedit and gnome-terminal.
Fixes#2958
The y was alround bounded but we allowed any x value and assumed the
caller would handle it. This is not the case so we now check the x and
return null if it's out of bounds (same as y, which was already doing
this).
Fixes#2958
The y was alround bounded but we allowed any x value and assumed the
caller would handle it. This is not the case so we now check the x and
return null if it's out of bounds (same as y, which was already doing
this).
Poor hash uniformity and/or a crafted or unlucky input could cause the
bounds of the PSL stats array to be exceeded, which caused memory
corruption (not good!) -- we avoid such cases now by returning an
OutOfMemory error if we're about to insert and there's an item with a
PSL in the last slot.
Related to #2731
I'm not fully sure if this will fix this issue since I can't reproduce
it but I don't see a downside to doing this and it might fix it.
Related to #2731
I'm not fully sure if this will fix this issue since I can't reproduce
it but I don't see a downside to doing this and it might fix it.
Fixes#2921
Our z-index handling was pretty much completely broken, hence I can't
think of a better initial commit message. We were splitting the
placements at the wrong points and just generally putting images in the
wrong z-index. I'm shocked this didn't come up earlier.
Fixes#2921
Our z-index handling was pretty much completely broken, hence I can't
think of a better initial commit message. We were splitting the
placements at the wrong points and just generally putting images in the
wrong z-index. I'm shocked this didn't come up earlier.
Previous logic had multiple issues that were hiding in edge cases of
edge cases with the ressurected item handling among other things; the
added assertIntegrity method finds these issues, the primary one being
an edge case where an ID is present in two different buckets.
Added more comments to explain logic in more detail and fixed a couple
little things like always using `+%` when incrementing the probe pos,
and replacing a silent return on an integrity issue that should be
impossible (`table[item.meta.bucket] != id`) with an assert.
According to the GNOME human interface guidelines, buttons for the main
user actions, such as new, add, open, and back should be placed at the
start of the header bar. (https://developer.gnome.org/hig/patterns/containers/header-bars.html#header-bar-buttons)
Moving the new tab button to the start of the header bar brings Ghostty
in line with other GNOME applications such as gedit and gnome-terminal.
There was an accidental use of `undefined` which I believe is the source
of crashes people are experiencing when drawing Powerline chevrons
(#3083). I've resolved this by using the slice from the path's internal
`ArrayList` instead of the backing array (`z2d` should probably
introduce a `getNodes()` method or similar to `StaticPath`), and also
annotated all `StaticPath` uses counting the maximum number of nodes
that may be required.
(**Edit**: confirmed, fixes#3083)
Annotate the node count of all uses of z2d `StaticPath` to verify
correctness, adjusted the size of a couple which were oversized, and
changed all painter calls that take node slices from `StaticPath`s to
use the slice from the wrapped `ArrayList` so that we don't include any
potentially `undefined` nodes at the end of the list, which I think was
causing a crash before.
Fixes#2092
This isn't perfect because it only prevents _new_ splits from being too
small. You can still resize the window to make them smaller. This just
helps prevent the very-easy-to-trigger crash of #2092.
We don't need to do this to macOS because it doesn't crash in the same
way with zero-sized splits.
Long term we should really chase down what breaks in GTK at a root level
when we have zero-sized splits. But this is a quick fix for now to
prevent the easy crash I feel like people might stress test and run into
with the 1.0 release.
Fixes#2092
This isn't perfect because it only prevents _new_ splits from being
too small. You can still resize the window to make them smaller. This
just helps prevent the very-easy-to-trigger crash of #2092.
We don't need to do this to macOS because it doesn't crash in the same
way with zero-sized splits.
Long term we should really chase down what breaks in GTK at a root level
when we have zero-sized splits. But this is a quick fix for now to
prevent the easy crash I feel like people might stress test and run into
with the 1.0 release.
From:
https://github.com/ghostty-org/ghostty/discussions/2363#discussioncomment-11645228
The justification there makes sense to me and I think it would be a good
change to make. Copied here:
> There are a few bindings that feel a little weird on macOS. My
suggestions:
>
> (1) Equalize Splits
> ```
> keybind = shift+opt+equal=unbind
> keybind = ctrl+cmd+equal=equalize_splits
> ```
> The default hijacks the `±` character on US keyboards. Believe it or
not, I do use ± in the terminal. Ctrl+cmd+equal matches the arrow key
bindings in the Window > Resize Split menu and thus looks more elegant
and is easier to memorize.
>
> (2) Jump to Prompt
> ```
> keybind = cmd+up=jump_to_prompt:-1
> keybind = cmd+down=jump_to_prompt:1
> ```
> These are the bindings in Terminal.app. The default shift-cmd-up/down
is usually associated with extending a selection. Cmd-up/down are
available (they currently act as simple up/down). I bind them
additionally to the defaults.
From: https://github.com/ghostty-org/ghostty/discussions/2363#discussioncomment-11645228
The justification there makes sense to me and I think it would be a good
change to make. Copied here:
> There are a few bindings that feel a little weird on macOS. My suggestions:
>
> (1) Equalize Splits
> ```
> keybind = shift+opt+equal=unbind
> keybind = ctrl+cmd+equal=equalize_splits
> ```
> The default hijacks the `±` character on US keyboards. Believe it or not, I do use ± in the terminal. Ctrl+cmd+equal matches the arrow key bindings in the Window > Resize Split menu and thus looks more elegant and is easier to memorize.
>
> (2) Jump to Prompt
> ```
> keybind = cmd+up=jump_to_prompt:-1
> keybind = cmd+down=jump_to_prompt:1
> ```
> These are the bindings in Terminal.app. The default shift-cmd-up/down is usually associated with extending a selection. Cmd-up/down are available (they currently act as simple up/down). I bind them additionally to the defaults.
Fixes#3072
Previously, when `window-theme = auto`, the appearance was delayed
enough on the DispatchQueue that the window was already visible. This
would result in the window appearing with the wrong appearance before
switching to the correct one.
For annoying reasons, we can't set the NSApplication.shared.appearance
in `applicationDidFinishLaunching` because it results in a deadlock with
AppKit.
This commit moves to set the `NSWindow.appearance` in `windowDidLoad`
(and any config sync) to ensure that the appearance is set before the
window is visible.
This is probably the right solution anyways because this allows windows
with different background colors to each have their own distinct
appearance.
Fixes#3072
Previously, when `window-theme = auto`, the appearance was delayed
enough on the DispatchQueue that the window was already visible. This
would result in the window appearing with the wrong appearance before
switching to the correct one.
For annoying reasons, we can't set the NSApplication.shared.appearance
in `applicationDidFinishLaunching` because it results in a deadlock with
AppKit.
This commit moves to set the `NSWindow.appearance` in `windowDidLoad`
(and any config sync) to ensure that the appearance is set before the
window is visible.
This is probably the right solution anyways because this allows windows
with different background colors to each have their own distinct
appearance.
In a [Discord
thread](https://discord.com/channels/1005603569187160125/1319727495473397791)
someone was having problems running Ghostty because they had
accidentally created a directory called `~/.config/ghostty/config`.
Instead of erroring out Ghostty would hang trying to "read" the
directory. Crashes can also happen if the argument to `--config-file` on
the CLI or a recursively loaded config file.
This patch prevents those hangs or crashes by refusing to read anything
but a plain file (symbolic links to plain files continue to work as
well).
Introduces static path methods and a reworked context API that makes
things generally cleaner.
This update incidentally fixed a bug we had before where the corner
triangle shade characters were drawn solid rather than medium shade.
### `Box_test_diff.ppm`:
Introduces static path methods and a reworked context API that makes
things generally cleaner.
This update incidentally fixed a bug we had before where the corner
triangle shade characters were drawn solid rather than medium shade.
Subsumes #2580 (which has multiple conflicts with main due to recent
changes to metrics); I figured it'd be easier to just implement it this
way.
#2580 claimed to solve #2487 but I don't think it really does- ideally
we can think of a good way to configure each individual cursor type, but
I don't wanna just do something ad hoc and add a bunch of config keys
blindly so I limited the scope of this.
Unicode 16 added "Separated Block Quadrants" from CP 0x0x1CC21 through
0x1CC2F:
To test, use the following command:
```
printf "\U0001CC21\U0001CC22\U0001CC23\U0001CC24\U0001CC25\U0001CC26\U0001CC27\U0001CC28\U0001CC29\U0001CC2A\U0001CC2B\U0001CC2C\U0001CC2D\U0001CC2E\U0001CC2F\n"
```
Which should look like this:
cc @qwerasd205 @rockorager
This adds a `+show-face` CLI action to show what font face Ghostty will
use to display a particular codepoint. The codepoint can either be
specified via a single integer or via UTF-8 encoded string.
## Description
Introduce a setting allowing to customize the behavior of the quick
terminal when it loses focus. By default, the quick terminal will
automatically hide. However, you can now configure it to remain open by
setting `quick-terminal-autohide: false`.
Resolves#2558
After upgrading Ghostty to the latest release, b92fb2d9, the unfocused
split color was quite different:
<img width="931" alt="image"
src="https://github.com/user-attachments/assets/9ff21db8-0280-416f-8119-2b0d1f08efc4"
/>
This was surprising because I don't set `unfocused-split-fill` so it
should use the background color.
I traced this to 298d6194f4c4de6727b6391b631d4d7f54d7f6b1 where the blue
and green components are divided by 255 but not the red.
Although I'm sure this should be easy to reproduce, the relevant bits of
my configuration file are included below:
```
theme = catppuccin-frappe
unfocused-split-opacity = 0.95
```
This fixes#3065.
