Attyx – tiny and fast GPU-accelerated terminal emulator written in Zig

2/25/2026 at 8:30:13 PM

Aside from the AI bits, "interesting" choice to use metal on MacOS, opengl on Linux, and skip Windows entirely.

by TheGoddessInari

2/25/2026 at 9:56:47 PM

i intentionally avoided windows because it's conceptually different from UNIX(-like) systems. for an early prototype like this it's just easier to manage because i share 90% of the codebase. real fork is just in the way i render things

by nicholasrq

2/25/2026 at 8:10:49 PM

Initial commit 3 days ago.

A zig-out/bin folder committed.

CLAUDE.md in the root.

README.md full of em-dashes, as are plenty of the doc comments.

Slop.

by messe

2/25/2026 at 8:17:20 PM

Nobody is writing a "project structure" section by hand, and listing out the directory structure with _every file_.

by ubercore

2/25/2026 at 9:55:33 PM

well, if it works, it works, right? sure requires some cleanup but i'm not saying it's super stable and all. my intention here is to bring some attention and maybe gain some feedback on what i'm building

by nicholasrq

2/25/2026 at 7:40:28 PM

What is the benefit of GPU acceleration?

My biggest gripe with things that I type into is the latency from keypress to when it shows on the screen. For instance, as I type this, I can clearly see a lag. If someone could come up with getting direct realtime raw access to keyboard to ensure there is zero perceptible latency (some chips that debounce switches can add even 50ms to keypress!), that would be something I'd love to have.

by varispeed

2/25/2026 at 8:25:55 PM

I don't understand all the hooplah about gpu-accelerated terminals either really. If your x/compositor(/framebuffer?) is using the correct drivers, isn't it already accelerated? (I've never really used "pretty" or overly featureful terminal emulators so is this about decoration? Or actually outputting text?)

by temp0826

2/25/2026 at 10:36:07 PM

it does have framebuffer of course because you need to store actual text somewhere. in this case framebuffer stores structs that contain text (char), its styles and dirtiness

all chars are rasterized into atlas (sprite, if you want) containing whatever can be printable. it's bitmap that has fixed addressable cells that renderer can pick up and apply styles to

so answering you question, it's not just outputting text, a bit more but super optimized to be really fast. i mean, visually it can be achieved by something like double-buffer so you basically just diff changes and re-render only changed cells

although, as i mentioned in another comment, in some applications CPU computations become too expensive. GPU acceleration just gives terminal snappier feel and prevent performance degradation under UI-heavy load

by nicholasrq

2/25/2026 at 10:53:19 PM

Can you post a video of the lag you see (with the sound of your keyboard as you type)?

That sounds like hell

by lacoolj

2/25/2026 at 9:59:37 PM

well, for most of the applications you probably don't need it. it's like a nice to have thing. it really kicks in is when you have a highly dynamic interface (mostly TUI do this). something like btop or similar. in this case rendering on CPU becomes expensive, terminal becomes less responsive and all. GPU rendering just unlocks parallelization. your stuff is running in pty, rendered with GPU and they don't interlock

by nicholasrq

2/25/2026 at 7:55:37 PM

> What is the benefit of GPU acceleration?

Yes, I'm also not clear on what is different between this and a PTY.

by bigwheels

2/25/2026 at 8:21:00 PM

> What is the benefit of GPU acceleration?

For claude to be able to use React as an engine to render its UI.

by skydhash