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
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
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.
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?)
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
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
Aside from the AI bits, "interesting" choice to use metal on MacOS, opengl on Linux, and skip Windows entirely.
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
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.
Nobody is writing a "project structure" section by hand, and listing out the directory structure with _every file_.
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
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.
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?)
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
Can you post a video of the lag you see (with the sound of your keyboard as you type)?
That sounds like hell
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
> What is the benefit of GPU acceleration?
Yes, I'm also not clear on what is different between this and a PTY.
> What is the benefit of GPU acceleration?
For claude to be able to use React as an engine to render its UI.