Smooth scrolling

[RGBCube]

As the title says, smooth scrolling (bonus points if the beizer curve is configurable) would be nice

[mitchellh]

Thinking about it.

[RGBCube]

Idea: Only scroll the lines that change, so the bottom bar in Vim or any other editor doesn't flicker. Would make a much smoother experience

[mitchellh]

Closed #1934 for this, really "merged" then. As we consider smooth scrolling we can address when the cursor is part of the scroll and how we can perhaps bring generalized animation into our renderers.

[mitchellh]

Converted this to a discussion because it isn't directly actionable and a significant amount of design work needs to be done. We can tear off actionable issues as we get there.

[sid314]

Getting smooth scroll working in programs like Neovim will be more difficult. For example take Neovide. In Neovide if you open a terminal inside Neovim, the smooth scroll dosent work inside that. That is bexause Neovim does its own thing inside that terminal and does not know that it is running inside Neovide.

[theherk]

My terminal in Neovide is smooth scrolling; both scrolling and long-running output. However, neovim inside a terminal running in neovide is again not smooth scrolling for the reason you point out. There needs to be knowledge about scrollable regions. But the terminal in Neovide is buttery smooth.

Even smoother than this video shows.
https://github.com/user-attachments/assets/f19c10b7-1deb-4795-953d-735b3d728864

[sid314]

Yes that is what i meant.

[sweiglbosker]

Ghostty is a terminal emulator, not a neovim client. This would be impossible to implement because there is no notion of partial scrolling in the terminal, just the redrawing of lines, cursor movement, and whatever else is described by ansi escape codes these days. Any attempt at adding smooth scrolling would only be as capable as something like tmux copy-mode.

[theherk]

Yeah I think I get your point, @sweiglbosker; I'm just disagreeing with it. As affably as possible, of course. I'm saying I see a future where Ghostty, Contour, Wezterm, and that ilk adopt, after its creation, a standard control code mechanism for scrolling regions in the viewport. From there, TUI's, will be able to send these instructions.

[sweiglbosker]

Yeah, the whole point of my argument was to say that we need a new protocol

[alicealysia]

except it literally has been implemented by a community patch already:
#3206

[sweiglbosker]

Okay i think im done restating my point after this lol, but if you actually read my message, i am talking about content aware partial scrolling (in lieu of #2355 (comment)) not pixelwise scrolling which is trivial to implement and support

[j4james]

@sweiglbosker Just FYI, the protocol for this does actually exist already. If an app wants to smoothly scroll an area of the screen, it can set the boundaries with DECSTBM and DECSLRM, enable the smooth scrolling mode with DECSCLM, and then output a linefeed or IND at the bottom of the margin area to trigger the scroll (or RI at the top of the margin area to scroll in the other direction).

When scrolling a large amount, and you don't want the delay of smooth scrolling, you just reset DECSCLM. You can even control the speed of the scrolling to some extent with the DECSSCLS setting. And on terminals that don't support this mode (or if it has been disabled), it'll just fallback to regular scrolling.

[pluiedev]

Let's just focus on scrolling on the primary screen for now - alternate screen smooth scrolling would likely require a separate protocol for defining partial scroll regions within TUIs, which is a much more complex task.

On the GTK side I think this will come naturally with #111. Instead of handling mouse events ourselves we should rely on GTK's scrollbar system, and map scrollbar positions into lines. Then, all we need to do to implement smooth scrolling is to support the idea of "fractional lines" in the renderer. Everything after that should come smoothly (pun intended).

[tonku321]

I think it would be good if something like this could be implemented through some terminal API that could be called from, for example, the nvim extension. Then there is no need to store code to support different programs in the ghostty repo, and different programs can implement their own behavior for pixel based scrolling.

for example this function will work well for nvim only if ui elements (statusline, ...) are not scrolled

[pluiedev]

As I said, let's focus on primary screen (aka non-TUI) scrolling for now. Alternate scrolling is a much more convoluted topic that I think warrants its own discussion, especially since it requires collaboration with TUI authors.

[theherk]

I don't disagree that smooth scrolling the viewport should be worked on first, but I do disagree that region scrolling discussion should be tabled. It is important to have this discussion early because the implementations will no doubt be closely related, and measuring twice before making a cut seems prudent.

Also, it doesn't require close collaboration with TUI's to implement. They will simply be able to make use of the API once implemented.

[pluiedev]

I think it wouldn't be as similar as you would imagine - firstly, having separate regions would likely mean we need to somehow partition the screen and store individual scroll metadata for each region, which requires a lot more extra data keeping in Ghostty core compared to storing a global fractional scroll offset. On the renderer side we either require issuing separate draw calls for each region, or put scroll data as a per-instance attribute instead of a shader uniform, and both approaches are very costly and far more complicated than what we can get by with in a full scroll on the primary screen, which is again literally just two variables.

We do need to collaborate with TUIs to gather what the use case is and how the ergonomics would be on their side when using the API. You can't make an informed design on an API if you don't even know what it would be used for and how it would be used, and by the time you need to adjust the design to cater to downstream needs, you don't have much room to make backwards-compatible changes. A bottom-up (from concrete cases to abstractions) approach here IMO would be necessary.

[dwt]

Regarding smooth scrolling of regions, it seems that dec vt320 terminals could do this in hardware. I have found some videos of this

• Dec vt320 smooth scrolling
• Playing with a DEC VT320

I do not have much information about that, but from what little I found, the terminal actually detected if a scroll happened in hardware. The first video clearly shows it scrolling only a part of the screen, so this was not limited to full screen scrolling.

I have also found this guy, who claims to have implemented this with custom controls sequences, but I'm not sure which terminal he is talking about.

[j4james]

@dwt The control sequence they're using is just the DEC scrolling mode (DECSCLM), although it's incorrectly represented in that article. It's a level 1 conformance requirement, so it should be supported by all DEC terminals from the VT100 onwards. Ghostty actually claims to support it, but last time I checked it didn't seem to have any effect.

[dwt]

As it doesn't seem to have been said in above discussion: Smooth scrolling for the main terminal window is really helpful, as it allows you to scroll fast and slow through huge volumes of text without loosing your reading position as easily.

This helps greatly with glancing through programs that generate a lot of output. For me, one prime example are docker builds, or ansible deployments. Especially the latter create huge output volumes in check mode that I need to quickly look through to see if there are unexpected changes.

And while of course that is possible with line scrolling (like it is implemented now) I like smooth scrolling much better and think it helps me with retaining context while scrolling as lines do not jump.

[sweiglbosker]

Agreed; for me things like animated cursor or smooth scrolling is not eye candy, but a QOL feature.