Scrolling flickers in builtin terminal

[skywind3000]

When you type:

ls -la /usr/bin

in vim's builtin terminal, you will see scroll is divided into two steps: first clear the screen, then render the text. see the GIF below:

Can it be fixed before 8.1 release ? tmux and other terminal will not flicker.

[brammool]

What system? What version of Vim? What terminal?

It's unlikely this can be fixed, libvterm is just not that efficient.

[skywind3000]

------ system information for last GIF recording --------
System: Debian 9 64 bits
Vim: 8.0.1707
Terminal: SecureCRT (on Windows 10)

But it can also be reproduced in GVim 8.0.1707 (Windows 10):

(capture2, flicker on windows gvim)

NeoVim uses libvterm too (if I remember correctly), terminal scrolling in neovim is fine:

(capture3, terminal scrolling in neovim)

[skywind3000]

My GVim was downloaded from:

https://github.com/vim/vim-win32-installer

[k-takata]

I think this is the same as #2010.

The patch was rejected because it might cause slowdown on certain conditions (e.g. remote terminal).
However I have never seen such slowdown with @mattn's patch even with a remote terminal.
I still think it's better to include the patch, and if we need to care about slow terminals we should only do ++RedrawingDisabled on GUI or when 'ttyfast' is set (as #2010 (comment)).

It seems that Bram has another idea (#2010 (comment)):

An alternative might be skipping the whole part of deleting lines under specific conditions.

But I still don't get the point.

[skywind3000]

So, it is a feature not an issue ?? But it doen't make me feel good especially in some low performance hardwares (like my Intel Celeron NAS).

[skywind3000]

btw, I don't know if it is the same issue, typing

dir c:\windows\system32

on windows gvim takes 21 seconds to scroll. gvim get stuck during this 21 seconds.

[chrisbra]

BTW: if you want to check out a patch, you can fork the win-vim32-installer repository, drop a patch in the patch directory and you need to adjust the appveyor integration (you need to change the secure token) and then build an updated binary with you patch enabled. That allows for easy testing of certain patches.

[k-takata]

So, it is a feature not an issue ??

#2010 was closed because Bram didn't think it was a right solution for the issue. (I'm not sure whether it is not a right solution, though.)

[skywind3000]

Time to consider introducing a new option ? like set termoptions+=s will enable smooth scrolling ?

[brammool]

> So, it is a feature not an issue ?? #2010 was closed because Bram didn't think it was a right solution for the issue. (I'm not sure whether it is not a right solution, though.)

The patch sets RedrawingDisabled and then executes code which doesn't do anything, since RedrawingDisabled is set. This is a terribly confusing thing to do, so we must not do that. If the scrolling is really only scrolling one line, then scrolling one line up and redrawing the one line should be faster. If not, then scrolling appears to be broken, and that needs to be fixed. If actually scrolling many lines, that should be detected and instead a redraw can take place. There is no need to check the type of terminal or anything. Checking 'ttyfast' or whether the GUI is running is a bad hack or workaround and not a proper solution. To summarize, what should probably happen is not scrolling right away, but counting the lines to be scrolled. Then when the redraw happens the total number of scrolled lines can be inspected. If it's just a few, a scroll should be faster. If it's many, just redraw the text.

…

-- panic("Foooooooood fight!"); -- In the kernel source aha1542.c, after detecting a bad segment list /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[k-takata]

Fixed by 8.0.1797 (6eddadf).

[skywind3000]

yes, scrolling is more smooth and faster now.

[brammool]

yes, scrolling is more smooth and faster now.

I discovered that it was always redrawing the whole window, also when only typing a single character. Plus only scrolling just before redrawing. It's still slow on Athena and Motif, but it doesn't show up with profiling, thus it's likely an inefficiency in the X11 libraries.

…

-- ARTHUR: I command you as King of the Britons to stand aside! BLACK KNIGHT: I move for no man. The Quest for the Holy Grail (Monty Python) /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///