GPU Architecture and Metal

The Multi-Renderer Core

Ghostty's performance hinges on a multi-renderer architecture built around a shared core, libghostty, written in Zig. This design decouples the core terminal emulation logic from the platform-specific rendering backend. The Zig core handles PTY parsing, state management, and grapheme clustering, exposing a stable C ABI for platform-specific frontends to consume.

This architecture allows Ghostty to achieve near-native performance on each platform. On macOS, it interfaces directly with Metal, Apple's low-overhead graphics API. On Linux and Windows, it falls back to a highly optimized OpenGL renderer. The result is a consistent, high-performance experience without the abstraction penalties common in cross-platform toolkits like Electron. The Zig core's control over memory layout and its direct compilation to machine code are key factors in achieving sub-100ms startup times.

Metal vs. OpenGL Pipelines

The choice between Metal and OpenGL is not merely about API availability; it's about leveraging the hardware to its fullest potential. Metal provides a more direct, lower-level path to the GPU on Apple hardware, minimizing driver overhead and enabling more predictable performance. This is particularly evident in tasks like shader compilation and resource management.

With hardware acceleration, the GPU (Graphics Processing Unit) is used to offload some of the processing effort from the more general-purpose CPU.

Ghostty uses this advantage to manage its rendering pipeline efficiently. The renderer batches glyphs into textures and uses shaders to handle everything from color to cell background rendering. While the rendering logic is similar between backends, the shader code is written in platform-specific languages: Metal Shading Language (MSL) for macOS and GLSL for OpenGL.

Here’s a conceptual comparison of a simple vertex shader in both languages.

// MSL (Metal Shading Language)
#include <metal_stdlib>
using namespace metal;

struct VertexOut {
    float4 position [[position]];
    float2 texCoord;
};

vertex VertexOut vertex_shader(
    uint vid [[vertex_id]],
    constant float2 *positions [[buffer(0)]],
    constant float2 *texCoords [[buffer(1)]])
{
    VertexOut out;
    out.position = float4(positions[vid], 0.0, 1.0);
    out.texCoord = texCoords[vid];
    return out;
}

And the equivalent in GLSL:

// GLSL (OpenGL Shading Language)
#version 330 core

layout (location = 0) in vec2 aPos;
layout (location = 1) in vec2 aTexCoord;

out vec2 TexCoord;

void main()
{
    gl_Position = vec4(aPos, 0.0, 1.0);
    TexCoord = aTexCoord;
}

While functionally similar, MSL's integration with the Apple developer ecosystem allows for pre-compilation of shaders at build time, reducing the first-frame latency that can occur with GLSL's runtime compilation model. This contributes directly to Ghostty's rapid startup.

GPU-Driven Rendering

Modern terminals like Ghostty, Alacritty, and Kitty have moved beyond CPU-based rendering. Ghostty leverages the GPU for nearly all visual tasks, including text layout, glyph rasterization, and UI composition. A critical performance bottleneck in terminals is handling complex text, especially with Unicode characters that require grapheme clustering (e.g., emoji with skin tone modifiers, or characters with diacritics).

Ghostty's Zig core performs this grapheme analysis once, then passes the structured data to the GPU. The GPU then renders the glyphs from an atlas, handling positioning and coloring in parallel. This approach avoids re-calculating layouts on every frame, allowing for lag-free scrolling through logs containing millions of lines. The entire grid of terminal cells is essentially a large texture on the GPU, updated only when cells change.

By offloading text rendering to the GPU, the CPU is freed to handle I/O and shell communication, resulting in lower input latency and higher throughput.

Configuration allows fine-grained control over GPU usage. The gpu-acceleration key in the configuration file can be set to On, Off, or Auto. On systems with multiple GPUs, Ghostty attempts to select the most performant device by default. However, you can force a specific device, which is useful on laptops with both integrated and discrete GPUs.

# Example ghostty config

# Enables or disables hardware acceleration.
# Options: "On", "Off", "Auto" (default)
gpu-acceleration = "On"

# On multi-GPU systems, you can specify a device by name.
# The name is vendor-specific (e.g., "NVIDIA GeForce RTX 4090" or "Apple M2").
# If unset, Ghostty picks the best available.
gpu-device = "Apple M2"

Performance Benchmarks

In performance comparisons, Ghostty's architecture demonstrates its advantages. Startup time is a key metric, where the lean Zig core and pre-compiled shaders on Metal give it an edge. Throughput, measured by how quickly the terminal can process a large stream of output (e.g., cat on a large file), is another area where its GPU-centric design excels.

Metric	Ghostty (Metal)	Alacritty (OpenGL)	Kitty (OpenGL)
Startup Time (cold)	~70ms	~120ms	~150ms
Throughput (MB/s)	~750	~700	~650
P99 Latency (scrolling)	< 8ms	< 10ms	< 12ms

These benchmarks are illustrative and vary by hardware. However, they consistently show that Ghostty's combination of a lightweight core written in a modern systems language and a rendering strategy that tightly integrates with the platform's native graphics API delivers exceptional performance, particularly on macOS where the Metal renderer can be fully utilized. The architectural choices directly address the performance bottlenecks found in older terminal emulators and even some of its GPU-accelerated contemporaries.

Quiz Questions 1/5

What is the core architectural principle behind Ghostty's high performance?

Quiz Questions 2/5

On macOS, how does Ghostty's use of Metal Shading Language (MSL) contribute to its fast startup times compared to using GLSL?

This focus on a tight, optimized core and platform-native rendering pipelines is what defines Ghostty's technical identity.

Ghostty Advanced Power User Guide