gtk3 gui substantially slower than gtk2

[RedBeard0531]

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

[Shougo]

https://groups.google.com/forum/#!topic/vim_dev/jaIrgS4LbsQ

[mcepl]

This seemed to get quite horribly worse in v8.0.0130 from https://copr.fedorainfracloud.org/coprs/mcepl/vim8/ . I have had almost a dozen previous builds with Gtk3 and this seems to be exceptionally worse.

[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

[mcepl]

yes, 567 feels much faster.

[mcepl]

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)

[dpelle]

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.)

[mcepl]

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

[RedBeard0531]

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-ml]

On Mon 26 Jun 2017 at 12:00:19 -0700, Mathias Stearn wrote: 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

Indeed. Gtk 3's client side rendering is a travesty and totally opposite 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. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.

[nuko8]

@RedBeard0531

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.