The Ghostty memory usage memes are dead with the upcoming 1.4 release, much to the dismay of internet trolls everywhere. ~10x less memory for a visible window. ~450x lower for a non-visible window. Very reasonable compared to other terminals with 10 tabs. This was the result of a lot of incremental hard work, but there were two big wins. One I talked about before which was scrollback compression. I want to note that these charts do NOT include scrollback, so with scrollback the results are more dramatic! The other big win is that we free almost all GPU resources when a window is fully occluded (covered by another window, minimized, etc.). We triple-buffer our screens so for large screens this has major savings. Those account for a large chunk of the improvements, but we also had dozens of incremental 1% wins here, a few KB there, etc. throughout the 1.4 cycle. And there are more coming! I noted before that Ghostty's memory waste was all in the app layer and we can see it here. libghostty has always been very tight in comparison and I've shown comparisons to other embedded terminal libraries elsewhere. And importantly, the charts below use the same grid sizes with a very small +/-2% difference due to differences in how cell metrics are calculated between terminals.

Ghostty (and libghostty!) now has a 100% complete implementation of the Kitty Graphics Protocol. We support every feature, every option. We are the first terminal beyond Kitty to do this. Most terminals stop at basic image placements, then give up on the long tail of other features. Ghostty covers all of them: - Unicode placeholders (so it works in tmux) - Relative placements (so images can be positioned relative to other images) - Animation - Scroll region handling (so images scroll properly with terminal scroll regions) - All transport mediums: shared memory, temp files, etc. - etc... All of these features don't impact steady-state use (CPU or memory, besides raw code size). And for libghostty consumers, you can use the compile-time features flags to disable them completely. I read the spec myself a hundred times. I read Kitty's source code to validate behaviors (our implementation is markedly different, so no GPL violation). I also utilized agents, primarily for validation. I spun Fable and Sol in a loop for 3 weeks (pausing only when their dedicated subs exhausted limits) with a prompt to find mismatches between the spec, Kitty's reference implementation, and Ghostty. And now we're done. Ghostty is the most compliant Kitty Graphics implementation (ignoring Kitty itself of course). And, this is all in libghostty, so now everyone can be perfectly compliant.

libghostty for WebAssembly got a lot of love recently and is now very, very, very good. I spent the day building harnesses and comparing to xterm.js and here are the results: faster at IO, faster at reflow, faster at rendering. Like, a lot a lot faster. We now provide pre-built `ghostty-vt.wasm` files in our GitHub releases. These are the fastest, most optimized builds that are compatible with every major browser going back a number of years. Before going over setups, I want to say that xterm.js is very good software. It is a relatively modern terminal, the maintainers are very nice, it's done incredible work for the web terminal ecosystem. I have nothing against them, but I'm in the business of making super fucking fast terminal emulators. Let me explain the setup in every case: IO throughput: This is an apples-to-apples comparison of `ghostty_terminal_vt_write` vs xterm's `Terminal.write(Uint8Array)` timed from first write to final completion callback. This is testing how fast a terminal emulator can process input and update internal state. Nothing else. Units are in MB/s processed. Note for graphemes: Ghostty has grapheme processing enabled and xterm.js does not (requires an addon). So, this shows how Ghostty does better despite having that cost. Column reflow throughput: Compares `ghostty_terminal_resize` to xterm's `Terminal.resize` with identical terminal states (same content, same size, same scrollback). The "dance" is rapid bigger/smaller resize of matching column widths, forcing text reflow. Units are in resizes/second. Render speeds: These test use the identical xterm.js WebGL renderer for both Ghostty and xterm.js. Since the renderer is identical, we can focus on how long it takes to prepare the inputs to the renderer (build the render state) and assert we get the same output byte-for-byte (since its the same renderer!). This is the truest way to measure these two because libghostty-vt itself does not provide a renderer, its about how long it takes to go from terminal state to render-ready. Full render: This tests a fresh renderer with nothing previously rendered. Units are in updates/second. Incremental render: This tests having prior state and only rendering specific changes such as adding scrollback, moving the viewport, moving the cursor. Units are in updates/second. This is using the latest released version of xterm in every case compared to the HEAD libghostty (since we haven't tagged a release, exact commit d760ee96e54657416eb427b793c7e839f003df7d).