Mac ligature rendering results in slow scrolling when cursorline is not set

[ychin]

Update to the latest version of MacVim and make sure to do this:

set macligature
set nocursorline
set norelativenumber

Scroll up and down using a trackpad, and make sure to use a high enough resolution screen so the lag is noticeable. To have a reproducible benchmark, you can also maximize MacVim, open a large file, and run this Ex command from the top of the file:

let g:profstart=reltime() | for i in range(1,30) | exec "normal \<C-E>" | redraw | endfor | echo reltimestr(reltime(g:profstart)) . " seconds"

This happens because in Vim, a couple commits went in to make sure cursorline (90a997987d and 1b7fefcbce) and relativenumber (bd9a53c06c) don't cause scrolling performance issues, but MacVim's ligature rendering function redraw_for_ligature is copied from the old redraw_for_cursorline which redraws the whole screen when scrolling instead of only updating the selected lines. I don't know if redraw_for_ligature can be so easily updated though, because it would require scanning the lines to see which line needs to be redrawn.

I think there's also currently a bug as a result, in that if cursorline is set, ligatures won't render correctly when you scroll because redraw_for_ligature explicitly decides not to do anything if it detects cursorline is on probably because it was relying on the old "clear everything" behavior.

[eirnym]

I didn't notice this during normal scrolling on 100000 lines file where each line has a few ligatures on it. However, this script indeed does have different execution times. With cursorline it runs very-very-very fast and smooth. My font is Fira\ Code:h12 and I have 54 lines on a screen

Could ligature function just use redraw_for_cursorline instead of having a separate one?

[ychin]

Also, see @254 for related discussions.