Ich hatte zwar noch keine Zeit, das Ding selber auszuprobieren, aber wenn das alles so stimmt, wird ein Traum wahr:
Alacritty’s renderer is capable of doing ~500 FPS with a large screen full of text. This is made possible by efficient OpenGL usage. State changes are minimized as much as possible. Glyphs are rasterized only once and stored in a texture atlas. Instance data for glyphs is uploaded once per frame, and the screen is rendered in only two draw calls.
Alacritty isn’t concerned with trying to only redraw what’s necessary. The entire screen is redrawn each frame because it’s so cheap.
Nominally, Alacritty will draw a new frame whenever the terminal state changes, and only when the state changes. Alacritty will simply sit idle when there’s no new data from the pseudoterminal or input events from the users. This helps significantly with battery life.
Alacritty is very good at processing huge amounts of text. Say that a user wants to cat 1gb_file.txt. There’s a lot of work for the parser to do. If Alacritty were drawing frames constantly on every change, it would take a long time to finish parsing and rendering the contents. Thankfully, V-Sync can help here.
V-Sync limits the frames drawn by Alacritty up to the monitor’s refresh rate. 60Hz is a typical value here. Using this number, there are 16.7ms available per frame. 2ms of that budget is occupied by the renderer, and the remaining 14.7ms are available to the parser to process that huge stream of text. Any text that is added to the terminal and scrolled past between frames will never be drawn. This is a huge performance win! The parser can process many MBs of data between frames, and the user will still see text drawn very smoothly.
Einen Terminal Emulator zu bauen, der seinen Output per GPU rendert, ist schon eine ziemlich geile Lösung. Ich freue mich drauf, das Ding bald mal auszuprobieren!