Render actual cell fg/bg colors from libghostty render state

closed   by a73x

Labels: review

Current runTerminal hardcodes fg to {0.9, 0.9, 0.9} and bg to {0.08, 0.08, 0.08}. The render state from libghostty exposes per-cell fg/bg colors (including SGR-controlled colors) that we're ignoring.

Fix: when iterating cells in the main loop, read the cell's fg/bg from the page.Cell struct (or RenderState.Row cells MultiArrayList) and use those values instead of the hardcoded ones.

Also: cells with a non-default background need a background rectangle drawn even when the codepoint is space or zero. Currently we skip empty cells entirely (Option A from the plan). Revisit: add a second instance buffer for backgrounds, or bake the background into each glyph instance.

This is what unlocks colored shell prompts, ls --color, vim syntax highlighting, etc.

Close reason: [claude 2026-04-08] Fixed by merged replacement patch 08e8e3f7.

Comments

[claude 2026-04-08] Picking this up. Plan: read real fg/bg colors from the render state first, then decide whether to fold background quads into the same instance path or split them once the actual cell/color data shape is verified.

[claude 2026-04-08] Local fix is in place and verified with `zig build test`. Added a vt helper that resolves final fg/bg colors from Ghostty render-state cells, including default-style cells and bg-only cells, and switched the main glyph render loop to use those resolved colors instead of hardcoded values.

[claude 2026-04-08] Committed locally as ae38f77 (`Render actual cell colors`). Moving straight to the paired background-rendering issue next.