[vim/vim] Improve to screen redrawing (Issue #10574)

monkoose

unread,

Jun 14, 2022, 3:45:33 PM6/14/22

to vim/vim, Subscribed

It's again that 'annoying' guy that is not happy with the current state of screen clearing/redrawing in vim and related issue #8002

I did more investigations, and have found that 'flickering' that i described caused by some CursorMoved autocommands (matchparen plugin, + I use popular lsp plugin coc.nvim that has some CursorMoved autocmds too) or some heavy calculations in statusline.

You can test it youself:

func! HeavyFunc() abort
  let x = 0
  for i in range(1, 8000)
    let x += 1
  endfor
endfunc

adjust loop so it wouldn't be too much visible when scroll
vim -u minimal.vim
set ls=2
invoke it on autocmd CursorMoved * call HeavyFunc() or set statusline=%{HeaveFunc()}
open some big file and scroll it with hold down C-f
If all done right there should be flickering or if HeavyFunc() is too slow even visible slow redraws of the screen.

So after my investigations what i understand the logic to clear and redraw the screen is:

Clear the screen
process all invoked autocmds and statusline calculations (something else?)
and only then add text to the screen.

Maybe it is possible to swap calculation of autocmds/statusline etc and clearing the screen? So it would be like

Caclulate autocmds and other required stuff
Clear the screen
Add text to the screen

Any limitations to achieve this?

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jun 15, 2022, 6:27:53 AM6/15/22

to vim/vim, Subscribed

> Hello, @brammool
>
> It's again that 'annoying' guy that is not happy with the current state of screen clearing/redrawing in vim and related issue #8002
>
> I did more investigations, and have found that 'flickering' that i described caused by some CursorMoved autocommands (matchparen plugin, + I use popular lsp plugin coc.nvim that has some CursorMoved autocmds too) or some heavy calculations in statusline.
>
> You can test it youself:

> ```vim

> func! HeavyFunc() abort
> let x = 0
> for i in range(1, 8000)
> let x += 1
> endfor
> endfunc

> ```
> - adjust loop so it wouldn't be too much visible when scroll
> - vim -u minimal.vim
> - set ls=2
> - invoke it on `autocmd CursorMoved * call HeavyFunc()` or `set statusline=%{HeaveFunc()}`
> - open some big file and scroll it with hold down `C-f`
> - If all done right there should be `flickering` or if HeavyFunc() is too slow even visible slow redraws of the screen.

>
>
> So after my investigations what i understand the logic to clear and redraw the screen is:

> - Clear the screen
> - process all invoked autocmds and statusline calculations (something else?)
> - and only then add text to the screen.

>
> Maybe it is possible to swap calculation of autocmds/statusline etc and clearing the screen? So it would be like

> - Caclulate autocmds and other required stuff
> - Clear the screen
> - Add text to the screen

>
> Any limitations to achieve this?

The flicker is most likely caused by using the clear-screen sequence.
If omitting that and displaying the text on top of what is there already
would avoid it, especially if the text didn't scroll. You can make a
vertical split to simulate this.

So long as the screen is cleared before redrawing yoo would always see a
little flicker, depending on how fast the text can be drawn. This
mainly depends on syntax highlighting.

--
SIGIRO -- irony detected (iron core dumped)

/// 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 ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

monkoose

unread,

Jun 15, 2022, 7:29:07 AM6/15/22

to vim/vim, Subscribed

So the question is is there any particular benefit of clearing whole screen before drawing it?
Is it faster, removes some possible left over artifacts? Any other reason?

And one of any of the questions above are important, why then if you split and make one window height only 1 line it doesn't require to clear the whole screen on big jumps (I understand that there different logic in implementations, I just don't understand why it requires in one situation, but not the other?) It is definitely that statusline after the jump would not go anywhere from your screen, so there is no reason to remove it in between screen drawing.

If omitting that and displaying the text on top of what is there already
would avoid it

That what I personally would like to have, but not sure about any issues or shortcomings this could strike with.

If you have time, can you explain or link to some resource, why screen should be cleared before drawing new info. Or this is just a strategy you have selected?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jun 15, 2022, 7:52:07 AM6/15/22

to vim/vim, Subscribed

> So the question is is there any particular benefit of clearing whole
> screen before drawing it? Is it faster, removes some possible left
> over artifacts? Any other reason?

Clearing the screen is required when the contents is unknown. E.g.
after executing a shell command. Otherwise it's to optimize the number
of characters sent to the terminal. This matters mainly over a remote
connection these days.

> And one of any of the questions above are important, why then if you
> split and make one window height only 1 line it doesn't require to
> clear the whole screen on big jumps (I understand that there different
> logic in implementations, I just don't understand why it requires in
> one situation, but not the other?) It is definitely that statusline
> after the jump would not go anywhere from your screen, so there is no
> reason to remove it in between screen drawing.
>
> > If omitting that and displaying the text on top of what is there already
> would avoid it
>
> That what I personally would like to have, but not sure about any
> issues or shortcomings this could strike with.
>
> If you have time, can you explain or link to some resource, why screen
> should be cleared before drawing new info. Or this is just a strategy
> you have selected?

We could perhaps have a way to prefer not to clear the screen.
This would work OK when using a fast (local) terminal and drawing is
slow enough to make flickering visible. This will require some work,
and risk that there are drawing artefacts.

--
LETTERS TO THE EDITOR (The Times of London)

Dear Sir,

I am firmly opposed to the spread of microchips either to the home or
to the office. We have more than enough of them foisted upon us in
public places. They are a disgusting Americanism, and can only result
in the farmers being forced to grow smaller potatoes, which in turn
will cause massive unemployment in the already severely depressed
agricultural industry.

Yours faithfully,
Capt. Quinton D'Arcy, J. P.
Sevenoaks

/// 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 ///

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

monkoose

unread,

Aug 4, 2022, 2:49:40 PM8/4/22

to vim/vim, Subscribed

Hello, @brammool

I have finally tracked this issue. Sorry for a lot of misleading recently.
I'm not sure why I didn't test it before, but option termguicolors and colorscheme with it support caused such flickering that i have described. Didn't test it before, because my colorscheme is gui only and not cterm.

Now i can fully reproduce with vim --clean -c "set nu rnu termguicolors laststatus=2" and open some big file and scroll with pressed C-f C-b causes a lot of statusline flickering. And :redraw! are sometimes flickers too (visible to an eye), but with notermguicolors redraw! my eye can't catch it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Aug 4, 2022, 3:28:30 PM8/4/22

to vim/vim, Subscribed

One thing you can do is using the "script" program. Run "script", edit some file with Vim that causes flicker, then exit Vim and exit script. Then the file "typescript" will show what was sent to the terminal. Perhaps that sows something.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

monkoose

unread,

Aug 4, 2022, 3:51:13 PM8/4/22

to vim/vim, Subscribed

While recording this logs have found that set t_ut= suggested by @lacygoill #8002 (comment) helped to completely remove flickering with vim --clean and other builtin colorschemes besides default one. But still have no impact to my config.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

monkoose

unread,

Aug 4, 2022, 4:03:39 PM8/4/22

to vim/vim, Subscribed

@brammool sorry for wasting so much of your time.
My full config with only changed colorscheme to any of builtin ones and set t_ut= option completely removed flickering for me.

Thank You.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

monkoose

unread,

Aug 4, 2022, 4:03:40 PM8/4/22

to vim/vim, Subscribed

Closed #10574 as completed.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

monkoose

unread,

Aug 4, 2022, 4:18:01 PM8/4/22

to vim/vim, Subscribed

Have tracked the issue.

Having Normal highlight with guibg=NONE and relate on the terminal background color caused such flickering.