[vim/vim] gtk3 gui substantially slower than gtk2 (#1199)
Mathias Stearn
I noticed that gvim was scrolling horrendously slowly after archlinux switched from gtk2 to gtk3 for gvim. Changing the build back to gtk2 solves the problem.
To reproduce: Open a file with many hundred lines in gvim and quickly scroll up and down using the mouse. It seems fine for small windows, but maximizing gvim on a WQHD (2560x1440) screen leads to many seconds of lag between when my finger stops scrolling and when gvim finishes moving. It is most painful with the mouse, but just holding j or k is also noticably slower once it has to start scrolling rather than just moving the cursor.
Original arch bug report: https://bugs.archlinux.org/task/51366
Arch build options for gvim: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/vim&id=2581bd2cfd91294e60f979f18b41256814724789#n69
Arch extra patches (for completeness, but I don't think they matter): https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/vim
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Shougo
Matěj Cepl
This seemed to get quite horribly worse in v8.0.0130. I have had almost a dozen previous builds with Gtk3 and this seems to be exceptionally worse.
malvina...@yahoo.com
--------------------------------------------
On Tue, 12/13/16, Matěj Cepl <vim-dev...@256bit.org> wrote:
Subject: Re: [vim/vim] gtk3 gui substantially slower than gtk2 (#1199)
To: "vim/vim" <v...@noreply.github.com>
Date: Tuesday, December 13, 2016, 2:12 AM
--
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
rebuia sa fie programul revolutiei din 1848? El era dezvoltarea progresiva a revolutiei
pmav99
Due to awesomeWM/awesome#1668 I tried to build gvim with gtk3 support and the current issue seems to be resolved. @RedBeard0531 @mcepl can you please test again?
@RedBeard0531 FYI I did not apply the archlinux patches:
#patch -Np2 -i "$srcdir"/0001-Fix-widget-sizing-on-current-Gtk-3.22-branch.patch
#patch -Np2 -i "$srcdir"/0002-Further-fix-widget-sizing.patch
Matěj Cepl
yes, 567 feels much faster.
Matěj Cepl
Taking back, 596 and couple of previous releases are as bad as before. with gqap I can even see the cursor redrawing individual lines on the display (and it is quad-core Thinkpad T420s with 11G of RAM)
Dominique Pellé
If someone can reproduce the speed difference between GTK2 and GTK3 GUI, I suggest to write a fully automated script to benchmark the speed difference, so that users can run it on various platforms. I suspect that the speed difference, if any, depends on platforms (version of GTK2/3, driver, etc.)
Matěj Cepl
I don't have a good reproducer but this is in the real time me pressing o https://mcepl.fedorapeople.org/tmp/extremely-slow-gvim.webm
Mathias Stearn
Sorry for the long delay in replying but I just tried upgrading to 8.0.0628 with gtk3 and it is still incredibly laggy, to the point of being painful to use. Just holding down j is painful since it seems to only move like 3-5 lines/second while my key repeat rate is 20/second.
The second email in the thread linked to by @Shougo above (https://groups.google.com/d/msg/vim_dev/jaIrgS4LbsQ/5TqzjcWRBgAJ) seems to imply that this is due to gtk3 waiting for each frame to render and be shown while gtk2 just sends the requests and lets them get displayed whenever the xserver decides to. While that email presents it in terms of gtk3 being more correct, as a user of a text editor, gtk2's behavior seems more desirable. I really don't care about the intermediate animation frames in gvim, I really just want it to reach the end steady-state as quickly as possible so that I can get on with the task at hand. Since I'm not rendering animation or watching a video, I really don't care about the "smoothness" of vim display frames. Is there any way to convince gtk3 to behave like gtk2 in this respect? Other gtk3 apps, including vte/gnome-terminal, don't seem to suffer this issue.
vim-dev ML
> The second email in the thread linked to by @Shougo above
> (https://groups.google.com/d/msg/vim_dev/jaIrgS4LbsQ/5TqzjcWRBgAJ)
> seems to imply that this is due to gtk3 waiting for each frame to
> render and be shown while gtk2 just sends the requests and lets them
> get displayed whenever the xserver decides to. While that email
> presents it in terms of gtk3 being more correct, as a user of a text
> editor, gtk2's behavior seems more desirable. I really don't care
> about the intermediate animation frames in gvim, I really just want it
> to reach the end steady-state as quickly as possible so that I can get
> on with the task at hand. Since I'm not rendering animation or
of how a proper graphics server should work. But it is adjusted to how
some people think that "the future" should look like in the form of
Wayland. See my .signature for how I think of *that*.
> watching a video, I really don't care about the "smoothness" of vim
> display frames. Is there any way to convince gtk3 to behave like gtk2
> in this respect? Other gtk3 apps, including vte/gnome-terminal, don't
> seem to suffer this issue.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.
Kazunobu Kuriyama
The second email in the thread linked to by @Shougo above
Let me clarify this: The thread @Shougo quoted is by no means our answer to your issue. I'm wondering what made you think it was. Actually I myself don't think the explanation given there applies to the issue here; it's an explanation as to some subtle but significantly important difference between GTK+ 2 and GTK+ 3, not an answer to any specific issue. Let's avoid confusion which may be resulted from a misquotation, or an inarticulate comment, if you will.
—
You are receiving this because you commented.
Nicolas
Is this still an issue?
—
You are receiving this because you commented.
Matěj Cepl
I have no idea, I am (not because of this) on neovim now, so I cannot contribute to anything gvim related.
—
You are receiving this because you commented.
Gautam Bhat
instead of gtk2 the scrolls are very very slow.
On Sat, Aug 24, 2019 at 8:05 PM Matěj Cepl <notifi...@github.com> wrote:
> I have no idea, I am (not because of this) on neovim now, so I cannot
> contribute to anything gvim related.
>
> —
> Reply to this email directly, view it on GitHub
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AASYIKEXAKU2R4SDCA6MEG3QGFBKZANCNFSM4CUFXUHQ>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Michał Gawron
I've recently fixed my Vim GTK slowness by setting an environment variable GDK_RENDERING=image. It's supposed to disable all hardware acceleration. This didn't just fix Vim performance for me, but also other GTK3-based programs.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Bram Moolenaar
Michał Gawron wrote:
> I've recently fixed my Vim GTK slowness by setting an environment
> variable GDK_RENDERING=image. It's supposed to disable all hardware
> acceleration. This didn't just fix Vim performance for me, but also
> other GTK3-based programs.
--
In his lifetime van Gogh painted 486 oil paintings. Oddly enough, 8975
of them are to be found in the United States.
/// Bram Moolenaar -- Br...@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 ///
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
sergio
GDK_RENDERING=image changes nothing for me: !seq 1000000 works like a hell.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Michał Gawron
Yes, for me !seq 100000 is still much slower than on a terminal (like ~400 lines per second in gvim), but in my case I had it even slower probably due to some issues between GTK3 and an Intel graphics card. Now I have at least usable gvim.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
sergio
400 lines per second is pretty good, I'd say:
https://sergio.outerface.net/misc/gvim-hell.webm (183KB)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Gautam Bhat
It has become worse in Ubuntu 20.04 LTS. I don't have any option as vim-gtk2 is not present in the repository.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
John Little
It has become worse in Ubuntu 20.04 LTS. I don't have any option as vim-gtk2 is not present in the repository.
Is there a reason you don't build your own vim with GTK 2?
(Just install libgtk2.0-dev, clone from github, and configure will find GTK2.)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Tony Mechelynck
It has become worse in Ubuntu 20.04 LTS. I don't have any option as vim-gtk2 is not present in the repository.
Is there a reason you don't build your own vim with GTK 2?
(Just install libgtk2.0-dev, clone from github, and configure will find GTK2.)
I used to build gvim with GTK2, then I upgraded to the beta of the next openSUSE Linux release (including a newer release of gcc), and got compiler warnings in every single module, beacuse GTK2 uses constructs which this new version of gcc considers "deprecated". Since there is no development being done on GTK2 anymore, and therefore no hope of making those warnings disappear in order to make "real warnings" more noticeable, I had to switch over to GTK3. But I don't notice the "substantial slowdown" about which the OP complains. It may (or may not) be related to the fact that I use plain Mesa video (without, I think, hardware acceleration) rather than the proprietary (and experimental) "nouveau" driver which openSUSE wanted to install by default.
Best regards,
Tony.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
John Little
Slightly related, the default Breeze theme in Kubuntu 20.04, and gvim with GTK3, causes a 600 ms delay "Starting GUI" as given by --startuptime. Changing the GTK3 theme away from Breeze reduces this to 200 ms.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
tojamrok
Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
Freshly installed Ubuntu 20.04.1 LTS
kernel 5.4.0-48-generic
XFCE desktop environment:
$ /usr/bin/time -f '%E' vim.gtk3 -g -c '!seq 1000' -c 'q'
0:03.65
$ /usr/bin/time -f '%E' vim.gtk2 -g -c '!seq 1000' -c 'q'
0:00.57
$ /usr/bin/time -f '%E' vim.athena -g -c '!seq 1000' -c 'q'
0:00.50
$ /usr/bin/time -f '%E' vim.gtk3 -g -c '!seq 10000' -c 'q'
0:29.43
$ /usr/bin/time -f '%E' vim.gtk2 -g -c '!seq 10000' -c 'q'
0:03.60
$ /usr/bin/time -f '%E' vim.athena -g -c '!seq 10000' -c 'q'
0:03.39
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Gautam Bhat
I had to switch over to GTK3. But I don't notice the "substantial slowdown" about which the OP complains. It may (or may not) be related to the fact that I use plain Mesa video (without, I think, hardware acceleration) rather than the proprietary (and experimental) "nouveau" driver which openSUSE wanted to install by default.
Best regards,
Tony.
@tonymec : Can you also try VIM via Xforwarding?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
gvimlag
I'm having the same problem with gvim in Debian-11.
See: #8861
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
Dominique Pellé
For me gtk3 is slower than gtk2 indeed, but the speed difference is not as dramatic as what @tojamrok reported.
I used:
cd vim/src
/usr/bin/time -f '%E' ./vim-gtk3 --clean -f -g -c '!seq 4000' -c 'q'
/usr/bin/time -f '%E' ./vim-gtk2 --clean -f -g -c '!seq 4000' -c 'q'
/usr/bin/time -f '%E' ./vim-motif --clean -f -g -c '!seq 4000' -c 'q'
/usr/bin/time -f '%E' ./vim-athena --clean -f -g -c '!seq 4000' -c 'q'
I measured 3 times in each config to assess how stable measurements are:
vim-gtk3: 0:07.10 0:07.16 0:07.09
vim-gtk2: 0:02.86 0:02.87 0:02.80
vim-motif: 0:01.65 0:01.66 0:01.63
vim-athena: 0:01.68 0:01.66 0:01.70
More info:
$ cat /etc/issue
Ubuntu 18.04.5 LTS \n \l
$ grep 'model name' /proc/cpuinfo | head -1
model name : Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
$ uname -r
4.15.0-156-generic
$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04)
$ ./vim-gtk3 --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Sep 12 2021 23:41:07)
Included patches: 1-3434
Compiled by pel@pel-cirrus7
Huge version with GTK3 GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
+balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
+browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand -perl +title
+channel +ipv6 +persistent_undo +toolbar
+cindent +job +popupwin +user_commands
+clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +virtualedit
+cmdline_hist +langmap -python +visual
+cmdline_info +libcall -python3 +visualextra
+comments +linebreak +quickfix +viminfo
+conceal +lispindent +reltime +vreplace
+cryptv +listcmds +rightleft +wildignore
+cscope +localmap -ruby +wildmenu
+cursorbind -lua +scrollbind +windows
+cursorshape +menu +signs +writebackup
+dialog_con_gui +mksession +smartindent +X11
+diff +modify_fname +sodium -xfontset
+digraphs +mouse +sound +xim
+dnd +mouseshape +spell +xpm
-ebcdic +mouse_dec +startuptime +xsmp_interact
+emacs_tags +mouse_gpm +statusline +xterm_clipboard
+eval -mouse_jsbterm -sun_workshop -xterm_save
+ex_extra +mouse_netterm +syntax
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/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/local/share/vim"
Compilation: clang-12 -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/x86_64-linux-gnu/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/harfbuzz -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/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang-12 -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 -ltinfo -lselinux -lcanberra -lsodium -lacl -lattr -lgpm -ldl
presuku
Hi all !
I have the same problem, but it fixed with bellow a patch in my environment.
However, this patch may have regression bugs that I don't know about (because I'm not gtk specialist),
but for now it works fine for me.
presuku@af73eef
before:
$ /usr/bin/time -f '%E' ./vim --clean -f -g -c '!seq 4000' -c 'q'
0:03.27
after:
$ /usr/bin/time -f '%E' ./vim --clean -f -g -c '!seq 4000' -c 'q'
0:00.30
More info: gprof top 10 of /usr/bin/time -f '%E' ./vim --clean -f -g -c '!seq 4000' -c 'q'
- gtk2
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
50.00 0.01 0.01 5168 0.00 0.00 post2nfa
50.00 0.02 0.01 4001 0.00 0.00 screen_del_lines
0.00 0.02 0.00 561063 0.00 0.00 utfc_ptr2len
0.00 0.02 0.00 77310 0.00 0.00 peekchr
0.00 0.02 0.00 68049 0.00 0.00 vim_strchr
0.00 0.02 0.00 67613 0.00 0.00 utf_ptr2cells
0.00 0.02 0.00 56961 0.00 0.00 utf_ptr2len
0.00 0.02 0.00 49074 0.00 0.00 utf_ptr2char
0.00 0.02 0.00 45127 0.00 0.00 frag
0.00 0.02 0.00 45127 0.00 0.00 st_pop
- gtk3 before this patch
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
66.67 0.12 0.12 196328 0.00 0.00 gui_gtk2_draw_string
22.22 0.16 0.04 192197 0.00 0.00 gui_screenstr
5.56 0.17 0.01 4009 0.00 0.04 gui_redraw_block
2.78 0.18 0.01 745 0.01 0.01 may_get_cmd_block
2.78 0.18 0.01 3 1.67 1.67 uc_add_command
0.00 0.18 0.00 592991 0.00 0.00 color_to_rgba
0.00 0.18 0.00 560930 0.00 0.00 utfc_ptr2len
0.00 0.18 0.00 419131 0.00 0.00 vim_free
0.00 0.18 0.00 227466 0.00 0.00 lalloc
0.00 0.18 0.00 227011 0.00 0.00 alloc
- gtk 3 with this patch
% cumulative self self total
time seconds seconds calls Ts/call Ts/call name
0.00 0.00 0.00 575829 0.00 0.00 utfc_ptr2len
0.00 0.00 0.00 77310 0.00 0.00 peekchr
0.00 0.00 0.00 68030 0.00 0.00 vim_strchr
0.00 0.00 0.00 67613 0.00 0.00 utf_ptr2cells
0.00 0.00 0.00 49074 0.00 0.00 utf_ptr2char
0.00 0.00 0.00 45401 0.00 0.00 utf_ptr2len
0.00 0.00 0.00 39835 0.00 0.00 in_vim9script
0.00 0.00 0.00 38391 0.00 0.00 skipwhite
0.00 0.00 0.00 35368 0.00 0.00 lalloc
0.00 0.00 0.00 34913 0.00 0.00 alloc
Bram Moolenaar
> Hi all !
> I have the same problem, but it fixed with bellow a patch in my environment.
> However, this patch may have regression bugs that I don't know about
> (because I'm not gtk specialist),
> but for now it works fine for me.
> before:
> ```
> $ /usr/bin/time -f '%E' ./vim --clean -f -g -c '!seq 4000' -c 'q'
> 0:03.27
> ```
>
> after:
> ```
> $ /usr/bin/time -f '%E' ./vim --clean -f -g -c '!seq 4000' -c 'q'
> 0:00.30
I suspect this does cause redrawing errors. Have you tried moving the
cursor up or down to cause the text to scroll?
It can perhaps be used as a hint, that copying an area is slower than
redrawing it. Hoever, this is unexpected, perhaps something in the
deleted lines was expensive. gui_gtk3_redraw() perhaps?
--
Very funny, Scotty. Now beam down my clothes.
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
lacygoill
After some days, I found more better solution.
So I created pr #9052.
Thank you for your contribution.
I don't know whether it has the same root cause, but I can still notice an issue in the GTK3 GUI (not GTK2); a command-line mode mapping which presses <C-R>= or <C-\>e causes the command-line to flicker (on 8.2.3607):
vim -Nu NONE -i NONE -U NONE -g +"execute 'cnoremap <C-A> <C-R>=' .. repeat('x', &columns)->string() .. '[-1]<CR>'"
# press : to enter the command-line
# keep pressing CTRL-A
That is, the contents of the expression is briefly printed on the command-line. That does not happen in the GTK2 GUI, nor in the TUI. <silent> fixes the issue, but creates another one (it might prevent the cursor from being redrawn in its new correct position).
presuku
I believe this flickering is a different issue than the performance issue.
vim renders text in command-line mode as followings steps in this case:
- clear command-line area
- render text (
=xxx...xxx[-1]) - re-clear command-line area
In gtk3, it just follow these steps to render and clear the text by gui_gtk2_draw_string() and gui_mch_clear_block(), so it appears to be flickering.
I'm not sure how TUI and gtk2 reduces redrawing in the command-line mode, but If text of step 2 does not need to display, I believe that vim does not need to render the text in step 2.
backtrace of step 2:
(gdb) bt
#0 gui_gtk2_draw_string (row=30, col=1, s=0x555555b4f197 <out_buf+23> "'", 'x' <repeats 112 times>, "\033|31;0Mx
#1 0x000055555583ff89 in gui_outstr_nowrap (s=0x555555b4f197 <out_buf+23> "'", 'x' <repeats 112 times>, "\033|31
#2 0x000055555583f6c8 in gui_outstr (s=0x555555b4f197 <out_buf+23> "'", 'x' <repeats 112 times>, "\033|31;0Mxx'[
#3 0x000055555583f480 in gui_write (s=0x555555b4f197 <out_buf+23> "'", 'x' <repeats 112 times>, "\033|31;0Mxx'[-
#4 0x00005555557de22f in ui_write (s=0x555555b4f180 <out_buf> "\"\b\033|30;0M\033|$\033|30;0M=\033|s'", 'x' <rep
#5 0x00005555557b60b4 in out_flush () at term.c:2549
#6 0x000055555563a00d in getcmdline_int (firstc=61, count=0, indent=0, clear_ccline=1) at ex_getln.c:1933
#7 0x0000555555639586 in getcmdline (firstc=61, count=0, indent=0, do_concat=1) at ex_getln.c:1562
#8 0x000055555574a263 in get_expr_register () at register.c:100
#9 0x0000555555638d1d in cmdline_insert_reg (gotesc=0x7fffffffc7f4) at ex_getln.c:1233
#10 0x000055555563a803 in getcmdline_int (firstc=58, count=1, indent=0, clear_ccline=1) at ex_getln.c:2039
#11 0x0000555555639586 in getcmdline (firstc=58, count=1, indent=0, do_concat=1) at ex_getln.c:1562
#12 0x000055555563b9a0 in getexline (c=58, cookie=0x0, indent=0, options=GETLINE_CONCAT_CONT) at ex_getln.c:2772
#13 0x000055555562211f in do_cmdline (cmdline=0x0, fgetline=0x55555563b95d <getexline>, cookie=0x0, flags=0) at e
#14 0x00005555556cc01f in nv_colon (cap=0x7fffffffd260) at normal.c:3425
#15 0x00005555556c7e76 in normal_cmd (oap=0x7fffffffd300, toplevel=1) at normal.c:1100
#16 0x0000555555888cc8 in main_loop (cmdwin=0, noexmode=0) at main.c:1502
#17 0x0000555555887fc2 in vim_main2 () at main.c:879
#18 0x00005555558876c5 in main (argc=10, argv=0x7fffffffd4f8) at main.c:426
archy3
For those experiencing this issue in a qemu/libvirt/virt-manager VM, I found changing the video model from QXL to Virtio almost made the issue unnoticeable. Slow scrolling is now only apparent if I intently focus on seeing if there's lag (i.e. if you're not looking for it, you won't see it).
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.