Could an interpolate-then-send approach allow good-enough pixel-perfect scrolling inside terminal apps?

[robinplace]

The problem I'm considering

I spend a lot of my CLI time in full-window apps e.g. Vim, less, & a half a dozen others. Because these take precedence over Kitty's scrollback buffer & therefore don't benefit from its pixel-perfect scroll implementation.

It seems to me that, with some tradeoffs, pixel-perfect scrolling in these full-window apps could be done.

Existing solutions I'm aware of

The status quo for terminal emulator scrolling in general, whether implemented by the OS or the application, essentially involves an "accumulator" that captures pixel-scale scroll events & then dispatches a full "line scroll" event once enough have been accumulated. This is fine & it's very easy to translate to full-window apps.

Extending on this, an experimental fork of Ghostty has an implementation that "bounces" the window on each "line scroll" event. It's interesting but on my Mac machine it's very glitchy & in general this approach will never capture the tactile value of pixel-perfect scrolling.

The solution I'm suggesting

I'd like to attempt, or see an attempt at, an implementation that offsets the terminal window's full contents with the value of the above-mentioned "accumulator". This offset would vary between zero & plus or minus the height of one line.

This implementation would result in fully-tactile smooth scrolling for the contents of an app!

The tradeoff, however, is that any fixed elements, e.g. the top & bottom bars, of the app would shake in place. For apps with very minimal fixed elements, e.g. Vim or Helix this would be relatively minor. I spend most of my full-window app time in minimal apps so this tradeoff would almost certainly be worthwhile for me.

For apps with more fixed elements, or apps with multiple scrollable panes, the shaking could be problematic. Turning on or off this feature based on e.g. a signal from the active app would help with that.

It's also worth noting that this for this to work smoothly, the app e.g. Vim & Kitty to both be on the same page as to how many lines a full "line scroll" event is scrolling. For best results this would probably always be 1. Many terminal apps have great support for configuring lines-per-event.

Next steps

If Kitty is open to this idea I'll use HTML & some JS to put together up a proof-of-concept visual mock to demonstrate the behavior. The key questions is whether the mechanism here actually produces tactilely pleasing results.

Once we have a visual demo it'd be much easier to evaluate if this's worth implementing or not.

[kovidgoyal]

No pixel scrolling in TUI applications needs a new escape code protocol to allow apps to ask the terminal to scroll regions of their window by pixel amounts. It's on my TODO list for someday.