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.
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
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?)
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.
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
Nobody is writing a "project structure" section by hand, and listing out the directory structure with _every file_.
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.
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
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?)
> 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.