21 Commits

Author SHA1 Message Date
Mitchell Hashimoto
b799462745 Better Glyph Constraint Logic (#7809)
This is a big'un.

- **Glyph constraint logic is now done fully on the CPU** at the
rasterization stage, so it only needs to be done once per glyph instead
of every frame. This also lets us eliminate padding between glyphs on
the atlas because we're doing nearest-neighbor sampling instead of
interpolating-- which ever so slightly increases our packing efficiency.
- **Special constraints for nerd font glyphs** are applied based roughly
on the constraints they use in their patcher. It's a simplification of
what they do, the largest difference being that they scale groups of
glyphs based on a shared bounding box so that they maintain relative
size to one another, but that would require loading all glyphs on the
group and I'd want to do that on font load TBH and at that point I'd
basically be re-implementing the nerd fonts patcher in Zig to patch
fonts at load time which is way beyond the scope I want to have. (Fixes
#7069)
- These constraints allow for **perfectly sized and centered emojis**,
this is very nice.
- **Changed the default embedded fonts** from 4 copies (regular, italic,
bold, bold italic) of a patched (and outdated) JetBrains Mono to a
single JetBrains Mono variable font and a single Nerd Fonts Symbols Only
font. This cuts the weight of those down from 9MB to 3MB!
- **FreeType's `renderGlyph` is significantly reworked**, and the new
code is, IMO, much cleaner- although there are probably some edge case
behavior differences I've introduced.

> [!NOTE]
> One breaking change I definitely introduced is changing the
`monochrome` freetype load flag config from its previous completely
backwards meaning to instead the correct one (I also changed the
default, so this won't affect any user who hasn't touched it, but users
who set the `monochrome` flag will find their fonts quite crispy after
this change because they will have no anti-aliasing anymore)

### Future work

Following this change I want to get to work on automatic font size
matching (a la CSS
[`font-size-adjust`](https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust)).
I set the stage for that quite some time ago so it shouldn't be too much
work and it will be a big benefit for users who regularly use multiple
writing systems and so have multiple fonts for them that aren't
necessarily size-compatible.
2025-07-05 14:37:46 -07:00
Mitchell Hashimoto
9ff77a5622 build: switch symbols over 2025-07-05 14:23:10 -07:00
Mitchell Hashimoto
43404bf4dc build: try again, also do symbol packages 2025-07-05 14:21:27 -07:00
Mitchell Hashimoto
28b54fe22b build: fix JBM zip to tar.gz 2025-07-05 14:10:28 -07:00
Mitchell Hashimoto
fb9c52ecf4 Nuke GLFW from Orbit
This deletes the GLFW apprt from the Ghostty codebase.

The GLFW apprt was the original apprt used by Ghostty (well, before
Ghostty even had the concept of an "apprt" -- it was all just a single
application then). It let me iterate on the core terminal features,
rendering, etc. without bothering about the UI. It was a good way to get
started. But it has long since outlived its usefulness.

We've had a stable GTK apprt for Linux (and Windows via WSL) and a
native macOS app via libghostty for awhile now. The GLFW apprt only
remained within the tree for a few reasons:

  1. Primarily, it provided a faster feedback loop on macOS because
     building the macOS app historically required us to hop out of the
     zig build system and into Xcode, which is slow and cumbersome.

  2. It was a convenient way to narrow whether a bug was in the
     core Ghostty codebase or in the apprt itself. If a bug was in both
     the glfw and macOS app then it was likely in the core.

  3. It provided us a way on macOS to test OpenGL.

All of these reasons are no longer valid. Respectively:

  1. Our Zig build scripts now execute the `xcodebuild` CLI directly and
     can open the resulting app, stream logs, etc. This is the same
     experience we have on Linux. (Xcode has always been a dependency of
     building on macOS in general, so this is not cumbersome.)

  2. We have a healthy group of maintainers, many of which have access
     to both macOS and Linux, so we can quickly narrow down bugs
     regardless of the apprt.

  3. Our OpenGL renderer hasn't been compatible with macOS for some time
     now, so this is no longer a useful feature.

At this point, the GLFW apprt is just a burden. It adds complexity
across the board, and some people try to run Ghostty with it in the real
world and get confused when it doesn't work (it's always been lacking in
features and buggy compared to the other apprts).

So, it's time to say goodbye. Its bittersweet because it is a big part
of Ghostty's history, but we've grown up now and it's time to move on.
Thank you, goodbye.

(NOTE: If you are a user of the GLFW apprt, then please fork the project
prior to this commit or start a new project based on it. We've warned
against using it for a very, very long time now.)
2025-07-04 14:12:18 -07:00
Qwerasd
c2484f48ef font: add jb mono and symbols-only nerd font as dependencies
Rather than using binaries statically in our source tree; this makes
them easier to update. This also makes it so that they are separated
from each other rather than using a patched JB mono as our fallback.
2025-07-03 15:59:04 -06:00
Qwerasd
8ed08aaecf deps: update zig-objc
This update also fixes a memory leak that was caused by blocks not being
deallocated and just collecting every single frame, slowly accumulating
memory until OOM.
2025-07-02 16:38:13 -06:00
Qwerasd
05eeaddb04 update flatpak hash 2025-06-30 11:21:50 -06:00
Mitchell Hashimoto
d0e12cc082 update libxev to workaround the io_uring regression in Linux 6.15.4
Fixes #7724

Background at the end of the commit message. The fix in libxev is
described in the PR and commit we pin to here, but basically we swap
read for poll for eventfd/timerfd.

From Jens Axboe on X:

> This will fix it: https://pastebin.com/n7JSZWpW which makes me suspicious
> that it's an S_IFREG check somewhere else, as anon inodes are now listed as
> regular files. Has potentially pretty broad implications...

> I think I can already answer why that breaks things - io_uring checks if
> this is a regular file, and if it is, it doesn't do short reads. Short
> reads on regular files (or a bdev) will cause application issues, as
> basically nobody expects them.

> Now we have what acts like a char dev, but where io_uring will retry IO
> because the application asked for more data than what was delivered. This
> will cause the weird slowdowns as data isn't delivered as soon as it's
> available.
2025-06-29 15:11:24 -07:00
mitchellh
2f978fbdcf deps: Update iTerm2 color schemes 2025-06-29 00:15:18 +00:00
mitchellh
fece388f58 deps: Update iTerm2 color schemes 2025-06-22 00:15:04 +00:00
Mitchell Hashimoto
43a46d1741 flatpak: update hash 2025-06-21 14:11:50 -07:00
mitchellh
3b33813071 deps: Update iTerm2 color schemes 2025-06-08 00:14:39 +00:00
mitchellh
b94d2da567 deps: Update iTerm2 color schemes 2025-05-25 00:15:05 +00:00
mitchellh
8a0ca1b573 deps: Update iTerm2 color schemes 2025-05-18 00:14:40 +00:00
mitchellh
db1608ff16 deps: Update iTerm2 color schemes 2025-05-11 00:14:21 +00:00
Mitchell Hashimoto
3c405a591a update flatpak cache 2025-05-06 07:19:40 -07:00
Mitchell Hashimoto
c7b8fd1354 flatpak: update dependencies 2025-04-27 07:00:24 -07:00
rhodes-b
ba5c773f0f update flatpak packages 2025-04-27 00:05:10 -05:00
Mitchell Hashimoto
946cf5a375 update flatpak build hash 2025-04-22 10:57:17 -07:00
Leorize
ebc169dbaf Fix flatpak packaging to a working state
This should make testing Flatpak builds a lot easier.

To build, enter `flatpak/` directory and run:

    flatpak-builder --repo=repo builddir com.mitchellh.ghostty.yml

alternatively, using org.flatpak.Builder flatpak:

    flatpak run -p org.flatpak.Builder \
      --repo=repo \
      builddir \
      com.mitchellh.ghostty.yml

The resulting flatpak can be installed using

    flatpak install ./repo com.mitchellh.ghostty

Credit of AppStream metadata goes to @yorickpeterse.
2025-04-22 10:56:09 -07:00