This is cool, but I gotta say - I care much more about keypress-to-screen latency on my terminals than throughput - would love to see some numbers on that.

▲

pg83 5 hours ago | parent [-]

It's VERY difficult to measure. But I can say that shitty has the best damage tracking model among foot/kitty/alacritty/ghostty. It's best in the sense that it's cell-exact; I only draw to the screen what has actually changed.

Furthermore, on Linux, I reuse buffers from the swapchain after the wayland compositor returns them, and I only update the areas that changed after I sent the buffer to the window system. In other words, I'm provably doing the minimum amount of work possible. Unfortunately, this isn't possible on MacOS, since the Metal documentation states that it can (and does) corrupt a buffer while displaying it.

Basically, based on code, not actual measurements, shitty is the best terminal in terms of change delivery latency.

▲

grg0 4 hours ago | parent [-]

> I'm provably doing the minimum amount of work possible.

That is a very bold claim to make for the amount of render code generated by the LLM. It's not obvious what the critical path even is, which is what would bound the latency. And I mean actual code, not just some informal description of what happens.

▲

pg83 4 hours ago | parent [-]

[flagged]

	▲	eru an hour ago \| parent [-]
		If you say 'provably', you should offer the proof. In Lean perhaps? But in English is also ok.