Very slow scrolling with gtk3

[Taylor Venable]

Hi, my distribution (Arch Linux) just switched to using the GTK3 build of gvim by default. But it behaves very poorly on my computer, the scroll speed is so slow that it's very difficult to use. With GTK2, everything is fine. Based on another thread about GTK3 performance showing output of a shell command, I used this test:



GTK3 VERSION

$ time ./vim -g -u NONE -U NONE -f -c ':!time seq 1 2000' -c 'q'

real 0m14.297s
user 0m2.143s
sys 0m0.070s



GTK2 VERSION

time ./vim -g -u NONE -U NONE -f -c ':!time seq 1 2000' -c 'q'

real 0m3.442s
user 0m0.313s
sys 0m0.030s



Quite a difference. :-) It's very noticable when moving around in a file. Both of these are compiled the way Arch Linux does for packaging, except that they were also compiled for profiling. I have attached the profiling output. Here is the version information:



GTK3 VERSION

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 29 2016 11:40:45)
Included patches: 1-13
Compiled by Arch Linux
Huge version with GTK3 GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_sgr +tag_old_static
+arabic +find_in_path -mouse_sysmouse -tag_any_white
+autocmd +float +mouse_urxvt +tcl/dyn
+balloon_eval +folding +mouse_xterm +termguicolors
+browse -footer +multi_byte +terminfo
++builtin_terms +fork() +multi_lang +termresponse
+byte_offset +gettext -mzscheme +textobjects
+channel -hangul_input +netbeans_intg +timers
+cindent +iconv +num64 +title
+clientserver +insert_expand +packages +toolbar
+clipboard +job +path_extra +user_commands
+cmdline_compl +jumplist +perl/dyn +vertsplit
+cmdline_hist +keymap +persistent_undo +virtualedit
+cmdline_info +lambda +postscript +visual
+comments +langmap +printer +visualextra
+conceal +libcall +profile +viminfo
+cryptv +linebreak +python/dyn +vreplace
+cscope +lispindent +python3/dyn +wildignore
+cursorbind +listcmds +quickfix +wildmenu
+cursorshape +localmap +reltime +windows
+dialog_con_gui +lua/dyn +rightleft +writebackup
+diff +menu +ruby/dyn +X11
+digraphs +mksession +scrollbind -xfontset
+dnd +modify_fname +signs +xim
-ebcdic +mouse +smartindent +xpm
+emacs_tags +mouseshape +startuptime +xsmp_interact
+eval +mouse_dec +statusline +xterm_clipboard
+ex_extra +mouse_gpm -sun_workshop -xterm_save
+extra_search -mouse_jsbterm +syntax
+farsi +mouse_netterm +tag_binary
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/etc/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
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-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/harfbuzz -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -pg -g -DWE_ARE_PROFILING
Linking: gcc -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -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 -fstack-protector-strong -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lieee -lm -pg



GTK2 VERSION

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Sep 29 2016 11:40:56)
Included patches: 1-13
Compiled by Arch Linux
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_sgr +tag_old_static
+arabic +find_in_path -mouse_sysmouse -tag_any_white
+autocmd +float +mouse_urxvt +tcl/dyn
+balloon_eval +folding +mouse_xterm +termguicolors
+browse -footer +multi_byte +terminfo
++builtin_terms +fork() +multi_lang +termresponse
+byte_offset +gettext -mzscheme +textobjects
+channel -hangul_input +netbeans_intg +timers
+cindent +iconv +num64 +title
+clientserver +insert_expand +packages +toolbar
+clipboard +job +path_extra +user_commands
+cmdline_compl +jumplist +perl/dyn +vertsplit
+cmdline_hist +keymap +persistent_undo +virtualedit
+cmdline_info +lambda +postscript +visual
+comments +langmap +printer +visualextra
+conceal +libcall +profile +viminfo
+cryptv +linebreak +python/dyn +vreplace
+cscope +lispindent +python3/dyn +wildignore
+cursorbind +listcmds +quickfix +wildmenu
+cursorshape +localmap +reltime +windows
+dialog_con_gui +lua/dyn +rightleft +writebackup
+diff +menu +ruby/dyn +X11
+digraphs +mksession +scrollbind -xfontset
+dnd +modify_fname +signs +xim
-ebcdic +mouse +smartindent +xpm
+emacs_tags +mouseshape +startuptime +xsmp_interact
+eval +mouse_dec +statusline +xterm_clipboard
+ex_extra +mouse_gpm -sun_workshop -xterm_save
+extra_search -mouse_jsbterm +syntax
+farsi +mouse_netterm +tag_binary
system vimrc file: "/etc/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "/etc/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
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/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -pg -g -DWE_ARE_PROFILING
Linking: gcc -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -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 -fstack-protector-strong -L/usr/local/lib -L/usr/lib/perl5/core_perl/CORE -lperl -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lieee -lm -pg



My system is an old Lenovo T500 with integrated Intel graphics. Here's a bit of information from lspci:

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

Here are the versions of GTK I'm using:

* gtk3 3.20.9
* gtk2 2.24.31

My kernel version for fun:

Linux thinkpad 4.7.5-1-ARCH #1 SMP PREEMPT Sat Sep 24 13:04:22 CEST 2016 x86_64 GNU/Linux



I hope this gives enough information to help identify the issue. Maybe it's not even a vim problem, but in case it is, I wanted to let you know. Please tell me if there's anything else I can do to help gather more information or test. Thanks for reading!

[Kazunobu Kuriyama]

2016-09-30 1:06 GMT+09:00 Taylor Venable <tcv...@gmail.com>:

Hi, my distribution (Arch Linux) just switched to using the GTK3 build of gvim by default. But it behaves very poorly on my computer, the scroll speed is so slow that it's very difficult to use. With GTK2, everything is fine. Based on another thread about GTK3 performance showing output of a shell command, I used this test:

<snip>

Let me talk about the latter issue on shell command output first.  I'll talk about the former issue on scrolling shortly after that.

I'm afraid it's not much relevant to scrolling.

Roughly speaking, when the GTK+2 GUI sends a series of drawing requests to the X server, it completely leaves to the server what eventually appears on the screen.  In other words, it doesn't care much about whether or not each frame is drawn on the screen.  Not a few frames could be skipped undrawn.

In contrast, the GTK+3 GUI  draws a complete picture on a off-screen first and then dump it at the server in accordance with a frame clock, so that every frame will surely be drawn on the screen.

Ensuring each frame is drawn is important to realize animation of high quality and considered to be one of inevitable features of modern GUI.

For those reasons, I'm now inclined to think that the performance test you're referring to doesn't make much sense for the purpose of comparison, because any GUI that cuts corners always beats a deadly earnest one at time race. :)

As for scrolling, I suspect the refresh rate of the display you're using, because GTK+ 3 uses a frame clock to update as noted above.

<snip> 

I hope this gives enough information to help identify the issue. Maybe it's not even a vim problem, but in case it is, I wanted to let you know. Please tell me if there's anything else I can do to help gather more information or test. Thanks for reading!

Thank you for sharing your time for Vim development and kind word to help us.

Best regards,

Kazunobu Kuriyama 

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Taylor Venable]

On Thursday, September 29, 2016 at 2:17:45 PM UTC-4, Kazunobu Kuriyama wrote:
> 2016-09-30 1:06 GMT+09:00 Taylor Venable <tcv...@gmail.com>:
> Hi, my distribution (Arch Linux) just switched to using the GTK3 build of gvim by default. But it behaves very poorly on my computer, the scroll speed is so slow that it's very difficult to use. With GTK2, everything is fine. Based on another thread about GTK3 performance showing output of a shell command, I used this test:
>
> <snip>
>
> Let me talk about the latter issue on shell command output first.  I'll talk about the former issue on scrolling shortly after that.
>
> I'm afraid it's not much relevant to scrolling.
>
> Roughly speaking, when the GTK+2 GUI sends a series of drawing requests to the X server, it completely leaves to the server what eventually appears on the screen.  In other words, it doesn't care much about whether or not each frame is drawn on the screen.  Not a few frames could be skipped undrawn.
>
> In contrast, the GTK+3 GUI  draws a complete picture on a off-screen first and then dump it at the server in accordance with a frame clock, so that every frame will surely be drawn on the screen.
>
> Ensuring each frame is drawn is important to realize animation of high quality and considered to be one of inevitable features of modern GUI.
>
> For those reasons, I'm now inclined to think that the performance test you're referring to doesn't make much sense for the purpose of comparison, because any GUI that cuts corners always beats a deadly earnest one at time race. :)
>
> As for scrolling, I suspect the refresh rate of the display you're using, because GTK+ 3 uses a frame clock to update as noted above.

Thank you for the information, I'm very ignorant about how this all works. If I'm reading you right, GTK3 should be smooth (if slow) because it ensures that every frame gets drawn. This test might not be comparable to scrolling, but it was far from smooth: I'd see a blank white window for a while, then numbers about 280 to 320 frozen on screen for 10 seconds (but at 100% CPU utilization the whole time), then the window would close. In contrast, with the GTK2 version, you could see the text flying by smoothly as I would expect. I use some other GTK3 apps like Emacs with performance issues. My monitor's refresh rate is 60Hz. Do you have any suggestions on how else I could investigate? Thanks again for your advice.

[Taylor Venable]

On Thursday, September 29, 2016 at 3:49:55 PM UTC-4, Taylor Venable wrote:
> I use some other GTK3 apps like Emacs with performance issues.

I'm sorry, this should have said "WITHOUT performance issues." :-)

[Kazunobu Kuriyama]

Really?  I think Emacs's "M! seq 1 2000" does not correspond to Vim's '":!seq 1 2000".  It rather corresponds to

function! EmulateEmacsMetaExclam()

  let cmd = input("Shell command: ")

  split

  wincmd w

  enew

  execute 'r!' . cmd

  normal! ggdd

  wincmd w

endfunction

nnoremap <Esc>! :call EmulateEmacsMetaExclam()<CR>

(Copy the snippet above and paste it into your ~/.vimrc.  Start vim and press <Esc> and ! in this order in normal mode, and you will get the prompt "Shell command: " on the command line window.

Type the string "seq 1 2000" there and press the return key.)

Is this slow on your machine in comparison with Emacs's M!?

[Taylor Venable]

Thanks, but it seems I have been unclear.

My problem is that, all other things being equal, scrolling through a buffer in gvim is very sluggish using GTK+ 3, compared to using GTK+ 2. This is not a problem that affects other GTK+ 3 applications. My example using the output of seq was only to illustrate how slow the scrolling is. Maybe a better example is:

$ vim -g -u NONE -U NONE /usr/include/stdio.h
--> then hold down the 'j' key

The movement is slow, the display lags, and when you let off 'j' it keeps going for a second. This doesn't happen in Emacs or gedit (both use GTK+ 3).

Sorry for the confusion before. This is not about how vim reads shell output. It's about the display speed under GTK+ 3.

[Kazunobu Kuriyama]

2016-09-30 9:51 GMT+09:00 Taylor Venable <tcv...@gmail.com>:

Thanks, but it seems I have been unclear.

My problem is that, all other things being equal, scrolling through a buffer in gvim is very sluggish using GTK+ 3, compared to using GTK+ 2. This is not a problem that affects other GTK+ 3 applications. My example using the output of seq was only to illustrate how slow the scrolling is. Maybe a better example is:

$ vim -g -u NONE -U NONE /usr/include/stdio.h
--> then hold down the 'j' key

The movement is slow, the display lags, and when you let off 'j' it keeps going for a second. This doesn't happen in Emacs or gedit (both use GTK+ 3).

So...the issue is not about "scrolling" or "shell command output", but "(downwards) vertical movement of the cursor", right?

I thought you were talking about your issue by making it relevant to the other issue you referred to, so I gave my explanation based on that, interpreting it as such.

Hmm...then the (possible) reason of the slowness is probably different from that, and I have no idea on what causes it yet.

Sorry for the confusion before. This is not about how vim reads shell output. It's about the display speed under GTK+ 3.

[Kazunobu Kuriyama]

2016-09-30 9:51 GMT+09:00 Taylor Venable <tcv...@gmail.com>:

<snip>

The movement is slow, the display lags, and when you let off 'j' it keeps going for a second. This doesn't happen in Emacs or gedit (both use GTK+ 3).

Probably, the interval of autorepeat is too small for the underlying graphics hardware to fulfill all the drawing requests on time.

How about increasing the value of the interval? 

It could be possible for vim to detect the refresh rate of the display and the frame clock of the GUI, and then overwrite the autorepeat setting accordingly.so that the GUI won't consume auto-repeated drawing requests beyond the hardware limitation.

By that, the GUI would behave like other GTK3 apps, though I personally prefer to leave such settings to users' discretion. 

Sorry for the confusion before. This is not about how vim reads shell output. It's about the display speed under GTK+ 3.

[Christian Brabandt]

Hi Kazunobu!

On Fr, 30 Sep 2016, Kazunobu Kuriyama wrote:

>
>
> 2016-09-30 9:51 GMT+09:00 Taylor Venable <tcv...@gmail.com>:
> <snip>
>
>
> The movement is slow, the display lags, and when you let off 'j' it keeps
> going for a second. This doesn't happen in Emacs or gedit (both use GTK+
> 3).
>
>
> Probably, the interval of autorepeat is too small for the underlying graphics
> hardware to fulfill all the drawing requests on time.
>
> How about increasing the value of the interval? 
>
> It could be possible for vim to detect the refresh rate of the display and the
> frame clock of the GUI, and then overwrite the autorepeat setting
> accordingly.so that the GUI won't consume auto-repeated drawing requests beyond
> the hardware limitation.
>
> By that, the GUI would behave like other GTK3 apps, though I personally prefer
> to leave such settings to users' discretion. 

It's the first time I hear about that. How would one set it?

Best,
Christian
--
Oh man, wenn ich bei Windows so viele Programme installiert hätte,
dann hätte ich schon 100mal rebooten müssen.
-- RealTimo unter Linux

[Kazunobu Kuriyama]

2016-09-30 16:20 GMT+09:00 Christian Brabandt <cbl...@256bit.org>:

Hi Kazunobu!

On Fr, 30 Sep 2016, Kazunobu Kuriyama wrote:

>
>
> 2016-09-30 9:51 GMT+09:00 Taylor Venable <tcv...@gmail.com>:
> <snip>
>
>
>     The movement is slow, the display lags, and when you let off 'j' it keeps
>     going for a second. This doesn't happen in Emacs or gedit (both use GTK+
>     3).
>
>
> Probably, the interval of autorepeat is too small for the underlying graphics
> hardware to fulfill all the drawing requests on time.
>
> How about increasing the value of the interval? 
>
> It could be possible for vim to detect the refresh rate of the display and the
> frame clock of the GUI, and then overwrite the autorepeat setting
> accordingly.so that the GUI won't consume auto-repeated drawing requests beyond
> the hardware limitation.
>
> By that, the GUI would behave like other GTK3 apps, though I personally prefer
> to leave such settings to users' discretion. 

It's the first time I hear about that. How would one set it?

Hi Christian,

As for autorepeat, please refer to the -r option of xset(1).

As for the refresh rate and the frame clock, I'm not sure if there're utility programs which are designed for ordinary users.

- Kazunobu

Best,
Christian
--
Oh man, wenn ich bei Windows so viele Programme installiert hätte,
dann hätte ich schon 100mal rebooten müssen.
                -- RealTimo unter Linux

[Taylor Venable]

On Fri, Sep 30, 2016 at 1:37 AM, Kazunobu Kuriyama
<kazunobu...@gmail.com> wrote:
> 2016-09-30 9:51 GMT+09:00 Taylor Venable <tcv...@gmail.com>:
>> My problem is that, all other things being equal, scrolling through a
>> buffer in gvim is very sluggish using GTK+ 3, compared to using GTK+ 2. This
>> is not a problem that affects other GTK+ 3 applications. My example using
>> the output of seq was only to illustrate how slow the scrolling is. Maybe a
>> better example is:
>>
>> $ vim -g -u NONE -U NONE /usr/include/stdio.h
>> --> then hold down the 'j' key
>>
>> The movement is slow, the display lags, and when you let off 'j' it keeps
>> going for a second. This doesn't happen in Emacs or gedit (both use GTK+ 3).
>
> So...the issue is not about "scrolling" or "shell command output", but
> "(downwards) vertical movement of the cursor", right?

These all cause the slowness:

* repeatedly using j / k when the cursor is at the bottom / top of the window
* repeatedly using page down / page up
* repeatedly using mouse wheel down / mouse wheel up
* clicking and dragging the scroll bar down / up

To me, these are all ways of scrolling the contents of the buffer
within the window. So I called it "Very slow scrolling with gtk3." The
taller the window, the slower it gets.

[Christian Ludwig]

Hi Taylor,

On 30/09/16 14:51, Taylor Venable wrote:
>
> These all cause the slowness:
>
> * repeatedly using j / k when the cursor is at the bottom / top of the window
> * repeatedly using page down / page up
> * repeatedly using mouse wheel down / mouse wheel up
> * clicking and dragging the scroll bar down / up
>
> To me, these are all ways of scrolling the contents of the buffer
> within the window. So I called it "Very slow scrolling with gtk3." The
> taller the window, the slower it gets.
>

just as explanation why the effects you see are not noticed by all
persons: Scrolling (in the meaning above) needs in gtk3vim a lot of CPU
power (CPU load is high during scrolling); much much higher than the CPU
load during scrolling in gtk2vim.

You said you had an older Laptop; obviously the CPU has not enough
"power" to calculate all the scrolling-actions of gtk3vim in time and
hence you notice the lag. Others don't notice (because their CPU can
compensate).

For me this effect was there since the start of gtk3vim [I'm the one who
wrote Issue 681]. And since then I hope for improvements ... [because I
really hope that scrolling in GTK3 can be done with nearly the same
amount of CPU-work than in GTK2.]

Bye
Christian L.