Very slow scrolling vim split screen

Question

When I scroll vim with j , k or the mouse wheel, it is very responsive and fast, but as soon as I open a new buffer in the scatter mode, the scrolling becomes very slow / delayed. This courageous happens in very large files (1000+ lines), even if the second buffer in the splitter screen is empty.

I reproduced this using different terminals. I also tried using ttyfast and lazyredraw , but none of them changed anything.

If I start vim with -u NONE , then this is the same thing, just not so noticeable.

What is the big difference in starting vim with and without splitting the screen in terms of scrolling and redrawing the screen?

EDIT:

I just realized that the problem only occurs with a vertical split. Horizontal split works great!

EDIT2:

The behavior appears only in the terminal version of vi / vim. As soon as I run gVim with the same configuration as vim, everything works like a charm even in a vertical split. I found someone with a similar problem in another forum. He received an answer that could be a problem, but not how to fix it. The answer was:

 That because the application has to repaint the screen rather than actually scrolling (since it cannot rely on the left/right halves of the display to scroll at the same rate). 

EDIT3:

I am running Ubuntu 13.10 - 64 bit. My computer specifications:

• Intel Core i7-4770K
• GeForce GTX 760 (nvidia-319 proprietary driver)
• 16 GB Ram

Here's the output of vim --version

 VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 12 2013 00:23:33) Modified by [e-mail] Compiled by buildd@ Huge version with GTK2-GNOME GUI. Features included (+) or not (-): +arabic +file_in_path +mouse_sgr +tag_binary +autocmd +find_in_path -mouse_sysmouse +tag_old_static +balloon_eval +float +mouse_urxvt -tag_any_white +browse +folding +mouse_xterm +tcl ++builtin_terms -footer +multi_byte +terminfo +byte_offset +fork() +multi_lang +termresponse +cindent +gettext -mzscheme +textobjects +clientserver -hangul_input +netbeans_intg +title +clipboard +iconv +path_extra +toolbar +cmdline_compl +insert_expand +perl +user_commands +cmdline_hist +jumplist +persistent_undo +vertsplit +cmdline_info +keymap +postscript +virtualedit +comments +langmap +printer +visual +conceal +libcall +profile +visualextra +cryptv +linebreak +python +viminfo +cscope +lispindent -python3 +vreplace +cursorbind +listcmds +quickfix +wildignore +cursorshape +localmap +reltime +wildmenu +dialog_con_gui +lua +rightleft +windows +diff +menu +ruby +writebackup +digraphs +mksession +scrollbind +X11 +dnd +modify_fname +signs -xfontset -ebcdic +mouse +smartindent +xim +emacs_tags +mouseshape -sniff +xsmp_interact +eval +mouse_dec +startuptime +xterm_clipboard +ex_extra +mouse_gpm +statusline -xterm_save +extra_search -mouse_jsbterm -sun_workshop +farsi +mouse_netterm +syntax 

Answer 1

In fact, you answered the original question:

 That because the application has to repaint the screen rather than actually scrolling 

This is what I do. When it scrolls slowly for me, not necessarily because splitting, I would try to use: 22j instead of j , 22 can be any number, it allows vim shift, and then calculate the scroll for each j .

Answer 2

Since the original question was answered, I would like to add my own solution, which seems to work for me with Vim 7.4.52 and Ubuntu 14.04.

I use tmux instead to vertically split the terminal window and run independent vim instances in each emulated terminal. In combination with vim-tmux-navigator , which allows smooth navigation between vim and tmux splits, the experience is much the same, but without stuttering when scrolling,

The only thing I missed is the ability to pull / paste from one buffer to another, but, of course, this is also solvable.