Laggy scrolling in (neo)vim on split window

[ruffson]

Describe the bug

When scrolling in neovim, the terminal output is really laggy compared to other terminals like kitty (see comparison below).

Environment (please complete the following information):

• OS: Fedora 34
• Version: I tried with a fresh release wezterm 20210502-154244-3f7122cb as well as the last nightly.
• The active keyboard layout name: US
• Hardware: Ryzen 9 5800HS

To Reproduce

1. Open a long file in neovim, e.g. the lorem.txt I attached
2. Open a vertical split window with :vs
3. Scroll down with j or ctrl+e
4. Close one of the split panes with :q and try again

Configuration

I am using neovim 0.5, tried disabling plugins like airline which seems to be have caused issues in the past. I also tried the currrent nightly which seems to be quite worse but hard to say. I attached a screencast with this minimal example but I also show a real world application which is considerably worse and compare that with kitty terminal.

My wezterm.lua:

local wezterm = require 'wezterm';
return {
  color_scheme = "MaterialOcean",
  font = wezterm.font("JetBrainsMono Nerd Font"),
  font_size = 13,
  warn_about_missing_glyphs = false,
  window_decorations = "NONE",
  enable_tab_bar = false,
  enable_csi_u_key_encoding = true,
  initial_rows = 40,
  initial_cols = 85,
}

Expected behavior

Smoother scrolling behaviour.

Screenshots

Simple example with the lorem.txt:

https://user-images.githubusercontent.com/1185812/119253897-8cc20e00-bbb3-11eb-8297-2943ea361fff.mp4

Real world example (split panes on the right, cut off here) with release:

https://user-images.githubusercontent.com/1185812/119253907-9d728400-bbb3-11eb-9034-77b4d6ebd261.mp4

Real world example (split panes on the right, cut off here) with nightly

https://user-images.githubusercontent.com/1185812/119253957-e9252d80-bbb3-11eb-9993-75b48ad80543.mp4

Real world example (split panes on the right, cut off here) with kitty:

https://user-images.githubusercontent.com/1185812/119253965-f6421c80-bbb3-11eb-9844-ef5a03975806.mp4

[Mic92]

I also sometimes feel that for local terminals the prediction in mux is causing these laggy scrolling as it predicts j,k not as editor movements: https://github.com/wez/wezterm/blob/bbadcb90e0341fd5201e401042ba82bf66d72646/wezterm-client/src/pane/renderable.rs

[wez]

I also sometimes feel that for local terminals the prediction in mux is causing these laggy scrolling as it predicts j,k not as editor movements:

@Mic92 Are you using a unix domain there? We should probably be smart enough to know that and not bother with prediction in that case.

[Mic92]

I also sometimes feel that for local terminals the prediction in mux is causing these laggy scrolling as it predicts j,k not as editor movements:

@Mic92 Are you using a unix domain there? We should probably be smart enough to know that and not bother with prediction in that case.

Yes. Exactly this is where it happens.

[Mic92]

Ok. I disabled the prediction. It does not remove the lagging but it no longer spams j and k characters when scrolling, which could be counted as a improvement. When doing my profiling with bcc like this:

sudo profile -F99 -f 5 > /tmp/profile

and than uploaded the result to https://www.speedscope.app/ I also saw that the mux server is spending a lot of time doing zstd compression. I reported this as a separate issue here: https://github.com/wez/wezterm/issues/867

[Mic92]

A different thing that I saw is that wezterm tries to open termininfo files from /home/joerg/.nix-profile/share/terminfo/ whenever I type something. This might explain some lacks when typing something and the system is doing heavy I/O. Here is the log of strace -o /tmp/weztrace -f ./target/debug/wezterm-gui

wez-strace.log

[Mic92]

The above script will only capture graphs, where the application is scheduled. However this will not catch all slow downs. If the application is waiting for locks or is de-scheduled while waiting for I/O, off cpu flamegraphs are required. Bcc has a tool called offcputime for that, it works similar to profile. Also explained in this article: http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html

[Mic92]

I uploaded an example profile sudo profile -F99 -f 10 > /tmp/profile here: profile.txt

One can open it by uploading it to https://www.speedscope.app/ While it was recording I was mainly scrolling in neovim. I recommend looking at the left-heavy pane in speedscope.

[wez]

@Mic92 I'd like to treat the multiplexer performance as distinct from this issue; we can use #867 to track that.

This issue (#817) is due to the GUI render cost being O(window-area), which has been reported with various symptoms across a couple of issues. That GUI render cost can influence perceived multiplexer latency: for example, the prediction only shows for me on a unix session when I make the window large, but it is a separate issue from the multiplexer.

[JeanMertz]

This issue (#817) is due to the GUI render cost being O(window-area), which has been reported with various symptoms across a couple of issues.

Are you positive this is the same issue?

I'm asking because I too notice a noticeable scroll stutter when I have split windows in NVim open, but the stutter goes away when I close all but one window.

This happens even if I have a relatively small terminal window open.

https://user-images.githubusercontent.com/383250/126312335-264d22ff-9129-479d-b35e-37baeb7454c8.mov

The same behaviour does not show up in either Terminal.app or Kitty.app.

[poetaman]

I have a bug on neovim, it happens irrespective of terminals: I have latest builds of alacritty, kitty, iterm2, terminal.

Please see the entire video at https://github.com/neovim/neovim/issues/14818, I also have simple steps and a test problem file attached there.

[fedoranvar]

i'm using neoscroll plugin , and noticing this problem only in unix domains, but in simple (local) - it's ok

[ViRu-ThE-ViRuS]

can confirm that this is still an issue, worsened when you have a terminal split open (with scroll back worth of output). You notice it when depending on high rate key repeat for scrolling using j/k, and less noticeable if at all when using things like {/} or <c-u>/<c-d> which I have mapped to (5, and 20 line navigation respectively)

When using kitty terminal, you can play around with the key repeat delay, increasing it to reduce the stutter a bit in neovim. This is also noticeable when using inside TMUX (worsened in fact, but need to test on latest)

[onurcanbektas]

I have the same issue on mac.

[MusabDev]

+1