GNOME Bugzilla – Bug 778966
severe input lag with ruler and one window mode due to gdk_pixbuf_scale() with themes using the pixbuf engine
Last modified: 2017-02-23 14:06:50 UTC
I see severe input lag in all the latest versions of GIMP that I've tested, including the latest git version from a few days ago. The input lag goes away if: - I hide the rulers - or disable single window mode By input lag I mean any brush or tool lags behind the cursor, sometimes by a few seconds. I created a short video to demonstrate: https://vimeo.com/204904842 Versions tested: release version 2.8.16 and dev version 2.9.5 from git commit f538eb2 For the dev version, I compiled the latest versions of a few dependencies as well: > ldd /usr/local/bin/gimp-2.9 | grep /usr/local | grep -v gimp libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x00007fc9874ae000) libgegl-0.3.so.0 => /usr/local/lib/libgegl-0.3.so.0 (0x00007fc9871e8000) libgegl-npd-0.3.so => /usr/local/lib/libgegl-npd-0.3.so (0x00007fc986fe0000) libbabl-0.1.so.0 => /usr/local/lib/libbabl-0.1.so.0 (0x00007fc986a12000) liblcms2.so.2 => /usr/local/lib/liblcms2.so.2 (0x00007fc9867b6000) libmypaint-1.3.so.0 => /usr/local/lib/libmypaint-1.3.so.0 (0x00007fc986169000) libpixman-1.so.0 => /usr/local/lib/libpixman-1.so.0 (0x00007fc982e37000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007fc982c04000) OS: Linux Mint 18 (Linux 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) CPU: AMD Athlon(tm) II X4 640 Processor GPU: NVidia GeForce GTS 450 Desktop: mate's marco window manager with no compositor There are a few other bug reports related to this one: 736411 - seemed to be for MS Windows, and resolved 763138 - blamed on Compiz? (My tests were run without compiz.) I would be happy to help out testing any potential fixes to this problem. I love gimp and use it all the time, only this one problem is driving me crazy... Thanks!
The user in bug 763138 didn't follow up to the last comments, so we do not know whether this was Compiz or not. As such, yours is the second report of this issue that I'm aware of. You could try to file this in the Linux Mint bug tracker (or post at a place where Mint users are around) to check if anyone else on your platform is seeing this, and might have found out what is causing it.
Confirming. I'm seeing a slight lag under similar conditions, although nowhere as dramatic. Kruthers, can you try switching to a theme that doesn't use the pixbuf engine (a high contrast theme, maybe, or one of the "classic" themes, like clearlooks), and confirm that the lag goes away? What happens is that in SWM, the rulers and the image notebook share a window, so that invalidating the rules causes the notebook's expose() to be invoked, which at some point calls gtk_paint_box_gap(), which, for the pixbuf engine, uses gdk_pixbuf_scale() on each call, which is what causing the slowdown. No idea why it's so dramatic for Kruthers, though. There's a similar problem with the scrollbars, although they're only updated frequently during panning, rotation, etc. so it's not as critical. Giving the shell its own window solves both issues.
As a side note, the default (booger green :P) mint theme uses pixbuf, it turns out, which expalins the 2.8 lag, and, of course, our dark theme also does.
Yes, that was it! I did not suspect themes to be related at all because those two examples were using very different themes. Changing to any of the other embedded themes in dev gimp did the trick; only the default selection of 03-Dark has extreme lag. And setting system theme (and using a different system theme) also fixed it. Also found out that my test of "moving the cursor around really fast" was useless, because it drives gimp to 100% CPU under any theme... And as for why the lag was so extreme on my system - I have no idea. I experimented with nvidia drivers, window managers and a few other things to no effect. Anyway, thanks for you help. I can at least use gimp without aggravation now. - K
Heh, I didn't even try that, but for some reason the other gray themes are indeed better behaved; the problem is still there, though. If you use a system theme that doesn't use the pixbuf engine at all, you shouldn't be seeing 100% CPU.
You know it felt like some of the not-insanely-slow themes were faster than others, but I couldn't figure out a good way to verify it and chalked it up to imagination. Ooc, how can you tell which ones use the pixbuf engine?
Fixed in master: commit 4c5f6a8e5b725014f2bc5db07224a14eed37ffd9 Author: Ell <ell_se@yahoo.com> Date: Wed Feb 22 18:31:39 2017 -0500 Bug 778966 - severe input lag with ruler and one window mode ... .. due to gdk_pixbuf_scale() with themes using the pixbuf engine Make GimpDisplayShell a subclass of GtkEventBox, so that it gets its own window, isolating its events from those of its ancestors. In particular, the "expose" event handler of GtkNotebook, which the shell is a child of in SWM, is particularly slow with themes that use the pixbuf engine. If the notebook and the shell use the same window, this can cause notable, and somtimes severe, lag when the rulers or scrollbars are updated frequently, such as when rapidly moving the cursor. app/display/gimpdisplayshell.c | 67 +++++++++++++++++++++++++++++++++++++++---------------------------- app/display/gimpdisplayshell.h | 4 ++-- 2 files changed, 41 insertions(+), 30 deletions(-) and in gimp-2-8: commit a0a7cf2dcbd6be3bc893a3640d7045c6a20ef7f4 Author: Ell <ell_se@yahoo.com> Date: Wed Feb 22 18:31:39 2017 -0500 Bug 778966 - severe input lag with ruler and one window mode ... .. due to gdk_pixbuf_scale() with themes using the pixbuf engine Make GimpDisplayShell a subclass of GtkEventBox, so that it gets its own window, isolating its events from those of its ancestors. In particular, the "expose" event handler of GtkNotebook, which the shell is a child of in SWM, is particularly slow with themes that use the pixbuf engine. If the notebook and the shell use the same window, this can cause notable, and somtimes severe, lag when the rulers or scrollbars are updated frequently, such as when rapidly moving the cursor. app/display/gimpdisplayshell.c | 67 +++++++++++++++++++++++++++++++++++++++---------------------------- app/display/gimpdisplayshell.h | 4 ++-- 2 files changed, 41 insertions(+), 30 deletions(-)
(In reply to Kruthers from comment #6) > Ooc, how can you tell which ones use the pixbuf engine? You can simply `grep pixmap /path/to/gtkrc` (usually /usr/share/themes/FooTheme/gtk-2.0/gtkrc) and see if you get anything. Anyway, it's all moot now. If you grab the latest version you should be able to use you favorite mucus-tinted theme without lag :)
I tested commit c11c955 against the previously evil themes and the problem is definitely gone. Also, I'm actually using gimp under compiz and not the basic, mucus-tinted test environment I used for the bug report (and video) and want to report that it works fine. :) Thank you!