[vim/vim] Stuttering cursorline in newer versions of vim (#8908)

[zim0369]

Instructions: Replace the template text and remove irrelevant text (including this line)

Description
I'm currently using the latest version of vim like always. I never use outdated packages. I've been experiencing cursorline stutter in vim. I don't experience it when using this plugin https://github.com/miyakogi/conoline.vim
That plugin does the job for me now. My config file . I've also experienced this with neovim and gvim.

Reproduce
Detailed steps to reproduce the behavior:

1. Run `vim with rnu cursorline cursorcolumn and maybe a theme so that the cursorline is more graphical and does not have any underline'
2. Edit more cluttered and heavy files
3. Keep scrolling until you see visual artifacts. Setting scrolloff as well would be better.

Expected behavior
Expected behavior would be simple smooth scroll. To visually feel it try the plugin mentioned above. That plugin has no lag.

Screenshots
none

Environment (please complete the following information):

• Vim version -> 8.2.3
• OS: Archlinux
• Terminal: urxvt and alacritty.

Additional context
You should really try installing the plugin mentioned in the description. It has a very smooth experience which is what I'd expect to have by default.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

[Christian Brabandt]

This is not very clear. Please start with vim --clean to reproduce and mention exactly how you scroll (mouse, keyboard, etc). Also please test the most recent vim version. It may also depend on what your $TERM is set to. There were some patches to make cursorline scrolling better, not sure why it did not help. It may also depend on you syntax scripts. so test with and without syntax highlighting please.

Second of all, this might depend on your system (e.g. graphics driver etc). So please give more details. And finally, it would probably need profiling to figure this out.

[zim0369]

This is not very clear. Please start with vim --clean to reproduce and mention exactly how you scroll (mouse, keyboard, etc). Also please test the most recent vim version. It may also depend on what your $TERM is set to. There were some patches to make cursorline scrolling better, not sure why it did not help. It may also depend on you syntax scripts. so test with and without syntax highlighting please.

Second of all, this might depend on your system (e.g. graphics driver etc). So please give more details. And finally, it would probably need profiling to figure this out.

Hey I've been able to trackdown the problem. The stutter during scroll occurs due to cursorcolumn. I'm sorry that I might not have been able to convey my problem in a report properly but this post on reddit might help.

[Yee Cheng Chin]

I played around and can see the issue too. In particular, if cursorcolumn and syntax on are both set, it seems to be really bad, regardless of whether cursorline is on (since I do remember there were some performance fixes regarding cursorline and relativenumber before).

I am using let g:profstart=reltime() | for i in range(1,50) | exec "normal \<C-E>" | redraw | endfor | echo reltimestr(reltime(g:profstart)) . ' seconds' to profile, and turning on cursorcolumn makes it 20x slower (From 0.02s to 0.40s) for me. I think maybe Vim is repainting the regions instead of issuing scroll commands but not sure. I was testing this on Apple Terminal which is not hardware accelerated. A hardware-accelerated terminal will probably be able to handle this better.

[zim0369]

I played around and can see the issue too.

I'm glad you noticed it. It was kinda' hard for me to explain. I mean it is pretty obvious to the eye but hard to convey in a textual format.

I was testing this on Apple Terminal which is not hardware accelerated. A hardware-accelerated terminal will probably be able to handle this better.

No. I tried this on Alacritty but didn't work as expected. I still see the same amount of stuttering. And gvim must be suffering from an existential crisis.

[Gabriel Linder]

Same here, I use mostly python files (syntax on, cursorcolumn and cursorline) and vim stutters with cursorcolumn but works fine with nocursorcolumn (no other changes, so this is not a cursorline issue).

Vim version 8.2.3455, tried on multiple terminals (alacritty, rxvt-unicode, st, xterm and zutty).

[Bram Moolenaar]

> > I played around and can see the issue too.
> I'm glad you noticed it. It was kinda' hard for me to explain. I mean it is pretty obvious to the eye but hard to convey in a textual format.
> > I was testing this on Apple Terminal which is not hardware accelerated. A hardware-accelerated terminal will probably be able to handle this better.
> No. I tried this on Alacritty but didn't work as expected. I still see the same amount of stuttering. And gvim must be suffering from an existential crisis.

To see whether Vim uses terminal commands to scroll text up or down or
redraws the text character by character, you can set the 'writedelay'
option. Just setting it to one might already work, otherwise try larger
values.

--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[zim0369]

There's not much info about 'writedelay' in vim help, but 'set writedelay=1' forces the entire terminal window to refresh for every action I do. In simple words content of the terminal is drawn from top to the bottom after every action.

[Christian Brabandt]

Also for gvim --clean? For me (with 'cursorcolumn' set and) going down one line using j it just redraws the area under the cursor in the old current line and the new current line (if the column doesn't change). If the column changes, Vim redraws the up to until the new (or old column) (depending on which one is farther to the right).

Perhaps some options negatively effect it (like relativenumbering, concealing, cursorline and cursorcolumn).

[zim0369]

Also for gvim --clean? For me (with 'cursorcolumn' set and) going down one line using j it just redraws the area under the cursor in the old current line and the new current line (if the column doesn't change). If the column changes, Vim redraws the up to until the new (or old column) (depending on which one is farther to the right).

Yes, you're correct. Only the area under the cursorline gets refreshed. I started editing from the top most line, that's why the whole window was being refreshed from top to bottom. Now I tried it with more operations and I've noticed :

• No line gets refreshed when inserting text but just the area around cursor on that specific line.
• When any operation makes the other lines move only then does the area below the cursorline gets refreshed/redrawn.
• The cursorcolumn is redrawn very frequently as compared to the cursorline because moving the cursor sideways doesn't redraw the cursorline, similarly moving the cursor up/down shouldn't redraw the cursorcolumn but since the cursor doesn't stay in the same column, the cursorcolumn has to be redrawn.

The frequent redrawing of the cursorcolumn explains a little bit of the 'steps to recreate' I made. I mentioned that scrolling through files with lines of variable length so that the cursor frequently moves back and forth causing the cursorline to lag but whenever the cursor was static along the row, keeping the cursorcolumn static as well, did not cause the curosorline to lag. So I think it must be the frequently redrawn cursorcolumn that's causing the lag.
Anyways, I don't know much about the technical stuff, so my assumptions could be terribly wrong.

[Bram Moolenaar]

> > Also for `gvim --clean`? For me (with 'cursorcolumn' set and) going

> > down one line using `j` it just redraws the area under the cursor in
> > the old current line and the new current line (if the column doesn't
> > change). If the column changes, Vim redraws the up to until the new
> > (or old column) (depending on which one is farther to the right).
>
> Yes, you're correct. Only the area under the cursorline gets
> refreshed. I started editing from the top most line, that's why the
> whole window was being refreshed from top to bottom. Now I tried it
> with more operations and I've noticed :

> - No line gets refreshed when inserting text but just the area around cursor on that specific line.
> - When any operation makes the other lines move only then does the area below the cursorline gets refreshed/redrawn.
> - The cursorcolumn is redrawn very frequently as compared to the cursorline because moving the cursor sideways doesn't redraw the cursorline, similarly moving the cursor up/down shouldn't redraw the cursorcolumn but since the cursor doesn't stay in the same column, the cursorcolumn has to be redrawn.

>
> The frequent redrawing of the cursorcolumn explains a little bit of
> the 'steps to recreate' I made. I mentioned that scrolling through
> files with lines of variable length so that the cursor frequently
> moves back and forth causing the cursorline to lag but whenever the
> cursor was static along the row, keeping the cursorcolumn static as
> well, did not cause the curosorline to lag. So I think it must be the
> frequently redrawn cursorcolumn that's causing the lag.
> Anyways, I don't know much about the technical stuff, so my
> assumptions could be terribly wrong.

Vim already does some optimization for redrawing the cursorline and
cursorcolumn, but at the same time the redrawing may require a full
redraw of lines when certain options are set, text is changed and syntax
highlighting is used, etc. We can't optimize every situation.

If you find the slow redrawing annoying, you'll have to disable the
cursorcolumn. Or find out what else matters, e.g. line numbering and
other options that change how text is displayed.

--
From "know your smileys":
¯\_(ツ)_/¯ Shrug

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[Yee Cheng Chin]

I can confirm that writedelay seems to suggest that Vim is correct only redrawing when necessary.

One weird thing I noticed was that vim --clean would not have the issue, but vim -u NONE -U NONE would. After mucking around a little, I think the set scrolloff=5 line in defaults.vim is helping out a lot, and if you set scrolloff back to 0, then you would see the slowed down scrolling more. Haven't investigated enough but just thought I would put it out why vim --clean may feel fine.

[zim0369]

Also for gvim --clean? For me (with 'cursorcolumn' set and) going > down one line using j it just redraws the area under the cursor in > the old current line and the new current line (if the column doesn't > change). If the column changes, Vim redraws the up to until the new > (or old column) (depending on which one is farther to the right). Yes, you're correct. Only the area under the cursorline gets refreshed. I started editing from the top most line, that's why the whole window was being refreshed from top to bottom. Now I tried it with more operations and I've noticed : - No line gets refreshed when inserting text but just the area around cursor on that specific line. - When any operation makes the other lines move only then does the area below the cursorline gets refreshed/redrawn. - The cursorcolumn is redrawn very frequently as compared to the cursorline because moving the cursor sideways doesn't redraw the cursorline, similarly moving the cursor up/down shouldn't redraw the cursorcolumn but since the cursor doesn't stay in the same column, the cursorcolumn has to be redrawn. The frequent redrawing of the cursorcolumn explains a little bit of the 'steps to recreate' I made. I mentioned that scrolling through files with lines of variable length so that the cursor frequently moves back and forth causing the cursorline to lag but whenever the cursor was static along the row, keeping the cursorcolumn static as well, did not cause the curosorline to lag. So I think it must be the frequently redrawn cursorcolumn that's causing the lag. Anyways, I don't know much about the technical stuff, so my assumptions could be terribly wrong.

Vim already does some optimization for redrawing the cursorline and cursorcolumn, but at the same time the redrawing may require a full redraw of lines when certain options are set, text is changed and syntax highlighting is used, etc. We can't optimize every situation. If you find the slow redrawing annoying, you'll have to disable the cursorcolumn. Or find out what else matters, e.g. line numbering and other options that change how text is displayed.
…

-- From "know your smileys": ¯_(ツ)_/¯ Shrug /// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net \\ /// \\ \\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

Okay. Closing the issue.

[zim0369]

Closed #8908.