gvim visual mode very slow, even with -u NONE

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

gvim visual mode very slow, even with -u NONE

John Z.
Hi all,
    I am having problems with graphical vim since not too long ago;
    terminal version works as great as always.

    The problem is that it became very choppy - there's about 500ms-1s
    lag between any keypress and reaction. Keypresses are queued, so if
    I rapidly type, they're executed in sequence, slowly.

    I am running archlinux with xmonad wm. Most of my apps run inside
    urxvt, with browser (palemoon) and gvim being the only graphical
    apps.
    I am running the compositor (compton), but killing it changed
    nothing.
    The hardware is nothing spectacular, 4y old laptop.
   
    What follows is list of things I tried before posting here:

    * updating my system, rebooting. No change.
    * vim -g -u NONE -U NONE. No change.
    * killing all other apps. No change.
    * comparing vim vs. vim -g. Terminal version runs normally.
    * strace $(pidof gvim). A gigazillion of failed recvmsg calls and
      few istats. I assumed this is normal behavior because it happens
      in terminal version too.
    * research on open issues: stackoverflow, stackexchange, vim wiki.
      Followed advice on changing fonts, didn't help. I don't use cursor
      lines and columns.
    * asked on #vim on Freenode. Got told to try with -u NONE, and try
      disabling compositor. Didn't help.
    * ldd vim to check which libs are used, went to check libpango and
      libcairo bug trackers for potential issues. Didn't find anything.


    I am not sure what is causing the issue. I found an advice to try
    alternative builds of gvim (using Athena), but before going down
    that road I'd like to try and see if I can fix this, especially
    because it might be affecting other parts of my system too - its
    just that the only symptom I see is in gvim.

    I don't know what else might be relevant. If there's anything,
    please ask.
   
    Sincerely,

   
--
"That gum you like is going to come back in style."

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20190612153841.GI1139%40johnslap.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: gvim visual mode very slow, even with -u NONE

Bram Moolenaar

> Hi all,
>     I am having problems with graphical vim since not too long ago;
>     terminal version works as great as always.
>
>     The problem is that it became very choppy - there's about 500ms-1s
>     lag between any keypress and reaction. Keypresses are queued, so if
>     I rapidly type, they're executed in sequence, slowly.
>
>     I am running archlinux with xmonad wm. Most of my apps run inside
>     urxvt, with browser (palemoon) and gvim being the only graphical
>     apps.
>     I am running the compositor (compton), but killing it changed
>     nothing.
>     The hardware is nothing spectacular, 4y old laptop.
>    
>     What follows is list of things I tried before posting here:
>
>     * updating my system, rebooting. No change.
>     * vim -g -u NONE -U NONE. No change.
>     * killing all other apps. No change.
>     * comparing vim vs. vim -g. Terminal version runs normally.
>     * strace $(pidof gvim). A gigazillion of failed recvmsg calls and
>       few istats. I assumed this is normal behavior because it happens
>       in terminal version too.
>     * research on open issues: stackoverflow, stackexchange, vim wiki.
>       Followed advice on changing fonts, didn't help. I don't use cursor
>       lines and columns.
>     * asked on #vim on Freenode. Got told to try with -u NONE, and try
>       disabling compositor. Didn't help.
>     * ldd vim to check which libs are used, went to check libpango and
>       libcairo bug trackers for potential issues. Didn't find anything.
>
>
>     I am not sure what is causing the issue. I found an advice to try
>     alternative builds of gvim (using Athena), but before going down
>     that road I'd like to try and see if I can fix this, especially
>     because it might be affecting other parts of my system too - its
>     just that the only symptom I see is in gvim.
>
>     I don't know what else might be relevant. If there's anything,
>     please ask.

What system is this on?  Some kind of Linux?
What GUI are you using?

Since it works OK in the terminal version the selection mechanism
probably works OK. But having half a second for updating the
highlighting is unlikely.  Can't guess what the problem is.

--
hundred-and-one symptoms of being an internet addict:
171. You invent another person and chat with yourself in empty chat rooms.

 /// Bram Moolenaar -- [hidden email] -- 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 received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/201906141112.x5EBCcxf022595%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: gvim visual mode very slow, even with -u NONE

Dominique Pellé
In reply to this post by John Z.
John Z. wrote:

> Hi all,
>     I am having problems with graphical vim since not too long ago;
>     terminal version works as great as always.
>
>     The problem is that it became very choppy - there's about 500ms-1s
>     lag between any keypress and reaction. Keypresses are queued, so if
>     I rapidly type, they're executed in sequence, slowly.

I recall experiencing something similar many years ago.
gvim (gtk2) was sluggish and vim in terminal was fast.
Refreshing the screen was slow when pressing page-down
Changing my video driver on Linux fixed it somehow.
I don't have more details, it was a long time ago.
I'm not sure if it's the same kind that you have.

Regards
Dominique

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAON-T_iaX1h68fuDYwThyK9KqiVEL09POVPFUo5yeaG1ZMp7pQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: gvim visual mode very slow, even with -u NONE

John Zezelic
In reply to this post by Bram Moolenaar
Hi Mr. Moolenaar,

> What system is this on?  Some kind of Linux?
> What GUI are you using?

I'm running Archlinux, with xmonad window manager, and generally as lean system as I can.
When you ask what GUI, I am not sure what you mean.

> Since it works OK in the terminal version the selection mechanism
> probably works OK. But having half a second for updating the
> highlighting is unlikely.  Can't guess what the problem is.

That's what I thought, too. Do you have any tips on how could I trace/profile vim, to get an insight on what is causing the hiccups? I'm thinking, if it gets stuck inside library call, maybe I can at least pinpoint which one and then research further.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/a6efa68d-97e9-40d5-8c3f-899bdf7bf667%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: gvim visual mode very slow, even with -u NONE

John Zezelic
In reply to this post by Dominique Pellé
> I recall experiencing something similar many years ago.
> gvim (gtk2) was sluggish and vim in terminal was fast.
> Refreshing the screen was slow when pressing page-down
> Changing my video driver on Linux fixed it somehow.
> I don't have more details, it was a long time ago.
> I'm not sure if it's the same kind that you have.

Hi Dominique,
I had similar idea, and thankfully I have a separate GPU in my laptop, so I tried running gvim using 'optirun' (which would -I believe- force it to use a different driver), but I experienced same issues.

--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/25a3f200-3eb6-4e2f-a4ad-efdc243bb9db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.