GPU resources allocated per-surface including hidden/inactive tabs

[ktsaou]

Issue Description

Each Ghostty surface (tab, split) allocates its own full set of GPU resources — framebuffers, renderbuffers, font atlas textures, cell buffers, uniform buffers — even when the surface is not visible (hidden tabs, occluded windows). These resources are never released until the surface is destroyed.

For users with many windows and tabs, this leads to significant GPU memory consumption. In my case, 20 windows with multiple tabs result in 674 MiB of VRAM consumed by Ghostty alone.

Source Code Analysis

Each Surface creates its own Renderer instance (src/Surface.zig:558), which creates its own swap chain (src/renderer/generic.zig:668). Each swap chain's FrameState allocates (src/renderer/generic.zig:343-406):

• A render target (OpenGL framebuffer + renderbuffer, sized to the surface's pixel dimensions) — src/renderer/opengl/Target.zig:34
• Uniform buffer
• Cell text buffer + cell background buffer
• Grayscale font atlas texture (duplicated per surface, even though SharedGridSet shares the CPU-side font grid)
• Color font atlas texture (same duplication)
• Background image buffer
• If custom shaders: 2 additional textures (front/back) + sampler + uniforms

When a surface becomes hidden (non-visible tab), the only optimization is:

• The display link is stopped on macOS (src/renderer/generic.zig:1057)
• Thread QoS priority is lowered on macOS (src/renderer/Thread.zig:277)
• Drawing is skipped if !self.flags.visible (src/renderer/Thread.zig:496)

But all GPU resources remain allocated.

Expected Behavior

Hidden/inactive surfaces should release their GPU resources (framebuffers, renderbuffers, per-surface atlas texture copies) when not visible, and reconstruct them on demand when the tab/split becomes active again. The reconstruction delay would be imperceptible (a few ms).

Why This Matters

This becomes a real problem when:

• Users have many windows/tabs (power users, developers running many sessions)
• The GPU is shared with other workloads (ML inference, gaming, etc.)
• Multi-monitor setups with high resolutions (each framebuffer is large)

Note: In PR #1584, @mitchellh acknowledged this area as a known gap:

"I think there are larger low-hanging fruit such as duplicate font information between multiple terminals, redundant CPU state for the renderer (when it's present already on the GPU), etc."

Ghostty Version

Ghostty 1.3.1
Linux (Manjaro), GNOME/Wayland
NVIDIA RTX 5090 (32 GB VRAM)
OpenGL 4.6 renderer

Environment

• 20 windows, multiple tabs each
• nvidia-smi reports Ghostty using 674 MiB VRAM

[tylerlaprade]

This is where I'm at.

[mitchellh]

Really good find on this, I'm sorry I missed this discussion. I'm working on this.

[mitchellh]

#14017