Very slow scrolling in vim's split screen

Question

When I scroll in vim using j, k or mouse wheel it is very responsive and fast, but as soon as I open a new buffer in split screen scrolling becomes very slow/delayed. It manly occurs in very large files (1000+ Lines), even if the second buffer in split screen is empty.

I reproduced this using different terminals. I also tried to use ttyfast and lazyredraw but none of them change anything.

If I start vim with -u NONE it is the same, just not as noticeable.

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

EDIT:

I just realized that the problem only occurs in vertical split. Horizontal split works fine!

EDIT2:

The behavior only appears using terminal version of vi/vim. As soon as i start gVim with the same configuration as vim everything works like a charm, even in vertical split. I found someone with a similar problem in an other forum. He got an answer what the problem may be, but not how to fix it. The answer was:

That's 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 specs are:

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

Here the output of vim --version

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 12 2013 00:23:33)
Modified by [email protected]
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

Actually you have answered the original question:

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

This is what I do When it scroll slow for me, not necessarily because the splitting, I'd try to use: 22j instead of j, 22 can be any number, it let vim do shifting rather then calculate the scrolling for each j.