10

I have a problem with gvim where the screen redraw partially fails. It's hard to explain but when I open a text file and page down or up the entire text file is not redraw properly. I have to move the cursor first before it redraws. I've got a screencapture here of it since it demonstrates the problem: http://www.box.net/shared/l4m1vrffl0dhigi80huz

It seems as if the issue is limited to gvim because every other application I run is fine and redraws properly. It's quite easy for me to reproduce in gvim. The console vim is fine. It makes me think the issue is limited to gvim.

OS is Arch linux 3.0 running the nvidia drivers running Gnome3 (no compiz).

Output from uname

Linux cyclops 3.0-ARCH #1 SMP PREEMPT Tue Aug 30 07:32:23 UTC 2011 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

lsmod

lsmod | grep nvidia
nvidia              10225284  40 
agpgart                22096  1 nvidia
i2c_core               16625  2 nvidia,i2c_nforce2

gvim --version

gvim --version VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 30 2011 05:51:10) Included patches: 1-322 Compiled by ArchLinux Big version with GTK2 GUI. Features included (+) or not (-): +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm

-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg +path_extra +perl +persistent_undo +postscript +printer -profile +python/dyn +python3/dyn +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent -sniff +startuptime +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard -xterm_save system vimrc file: "/etc/vimrc" user vimrc file: "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file: "/etc/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file: "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/usr/share/vim" Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/local/include -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=1 Linking: gcc -L. -Wl,--hash-style=gnu -Wl,--as-needed -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -L/usr/local/lib -Wl,--as-needed -o vim -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE -lm -lncurses -lelf -lnsl -lacl -lattr -lgpm -ldl -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -fstack-protector -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -lruby -lpthread -lrt -ldl -lcrypt -lm -L/usr/lib

5
  • 2
    I have this same exact problem in Ubuntu 12.10, under Gnome 3. You are the only other person on the internet that I've found to have it. Any luck since posting this?
    – jakar
    Mar 6, 2013 at 3:17
  • @jakar No I never found a way to fix this. I'm now running fc17 with nvidia drivers and don't see the problem anymore, but I'm not using Gnome 3 in it's fancy mode.
    – sashang
    Mar 6, 2013 at 5:38
  • Yeah, I think it has more to do with gnome/gtk/xorg/drivers than with gvim itself. I don't have any problems in fc17 either (though on a different machine), even running matching versions of gvim, built from source. Oh well, I'll live with it for now. At the very least, thanks for the only good description and video of this that I've seen.
    – jakar
    Mar 6, 2013 at 21:35
  • I also have this problem. I'd be really interested in a solution. Mar 16, 2014 at 12:12
  • 3
    This sounds a lot like issue 91 and my current guess is, that this is a gtk library issue. Mar 24, 2015 at 17:56

4 Answers 4

6

I had this problem and was able to get around the issue by starting gvim with the --sync option. This makes X calls asynchronous.

(Thanks to the link in Christian Brabandt's comment for pointing me in the right direction.)

1
  • Had this same problem running Debian/9 in a virtualbox machine on top of integrated graphics. Same symptoms of missing redraws - splitting the buffer does not update the display until alt-tabbing to another app and back. The --sync switch fixed the issue.
    – Andrew
    May 14, 2019 at 9:57
0

It would help to provide info on your OS, video card, etc. Looks like GNOME3 on ...?

I had a problem like this when running GVIM and other apps with Compiz as my Window Manager with an NVIDIA video card, and fixed it by going to "Compiz Config Settings Manager" > Workarounds > check "Qt Window Fix".

No clue if this, or something else, will help in your case or not, especially if you're using Mutter instead of Compiz.

0

What kind of plugins do you have jacked into Vim beyond what came bundled out of the box?

There may be a chance one of your normally stable plugins went a little glitchy on you. Yes, GTK is revealing the problem, but it is likely not THE problem. Anything that creates popup-windows or temporarily creates a mini-buffer or something like that. Autocompletion, snippets, ... If its an extra plugin or feature, try turning it off and see if your issue goes away.

Although I did not see any such popups in your movie, the plugin may be creating its popup, realizing its not actually needed, clearing the popup, but then not redrawing the content that was originally underneath.

Doing a full screen scroll does not repaint the entire buffer. Cursor is obviously forcing the buffer to repaint neighbors.

Of course it could be a core GTK/GVim problem (I think that X or OpenGL have nothing to do with it), but it seems unlikely to me (although I don't commonly use Arch).

If you do find that its a plugin, you may want to force a version upgrade or downgrade (anything but the "broken" version).

0

FWIW I got rid of the problem by installing the package vim-gtk3, replacing vim-gtk (Ubuntu).

NOTE! For some reason the default gvim command was not mapped to vim-gtk3 when i installed the package so i had to run update-alternatives manually like so:

sudo update-alternatives --set gvim /usr/bin/vim.gtk3

Thanks a lot for the hints in this thread that GTK might be the problem. This problem was hard to track down even using Google!  

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .