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
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
reply