GNOME Bugzilla – Bug 736411
Ruler updates cause slowdown when painting (was: Brush lag in Single-Window mode.)
Last modified: 2015-10-21 09:55:46 UTC
It took me a while to find out what was going wrong but now I think I've found the culprit. If I use my wacom in Singe-Window mode there is a huge lag making it impossible to paint or to do anything that requires the use of the tablet. But in the old Non-Single-Window mode the lag disappears. Can someone please confirm this and if it's valid please fix it soon. Thank you.
Additional info. It seems the lag exist in Non Single-Window mode also. But it is related with the size of the window that has the canvas. If it is small (about 600x400 pixels) the lad is gone. If I resize it to make it bigger the lag comes back :-g
I don't see any increase in lag when I increase the window size on Linux/X11. This must be related to how the Windows GDK backend manages buffers or how it transfers them to Windows.
On gimpforum.de, we also tried to find out, what causes this extreme lag. A user pointed out, that for him the paint dynamics seem to cause the problem. With paint dynamics disabled, everything works fine (even while using a graphics tablet). But as soon as he enables the dynamics, everything becomes laggy, no matter which dynamics-preset he uses (even a new preset with no function at all did not change anything).
I have a similar bug but it's neither related to brushes, single window mode or tablet. When I use selection tools (rectangle, ellipse and free) it's all laggy where in 2.10 it was smooth enough. But indeed, the more I reduce the window size the more it becomes smooth.
Do you use the updated installer? Please try http://download.gimp.org/pub/gimp/v2.8/windows/gimp-2.8.14-setup-1.exe and report back.
Yes, I use the latest version (gimp-2.8.14-setup-1). At first I thought there was some incompatibility with gimp-paint-studio that I use. So I made a clean install. I even cleaned all gimp settings from the User's folder. Same results. I also use the latest wacom drivers. If I use wacom without its drivers (which it then becomes a regular mouse) there is no lag. The moment pressure sensitivity is used, the lag is back. The weird thing is, as I wrote earlier, if the window that has the canvas is small then the lag is gone. It's just not feasible to work in such a small area.
This has been happening since some versions back as I already reported (https://bugzilla.gnome.org/show_bug.cgi?id=696148). I don't know why it works but if you download libcairo and libpng binaries from GTK2 branch and put them under the gimp/bin folder of your install location it works.
It would be nice if this was fixed officially without any hacking from regular users needed.
This is being worked on, in particular by: - finding the change in libcairo that causes it (via git bisect from a known good version to the current one - help the libcairo developers to fix it, if possible We do not want to ship current GIMP installers with old versions of libraries. Bug 736220 contains links to corresponding bugs in the libcairo bug tracker.
It may be worth adding that I have the same problem with my Wacom Bamboo tablet, and for me it is linked to the visibility of the rulers. The little black arrows on them lag behind the cursor at all times. Hiding the rulers makes the lag disappear immediately, leaving no issues with any of the tools whatsoever.
Nice find there, Jutt. I tested in my PC and the rulers are those that produce the lag. Just hide the rulers and the lag is gone. You don't even have to restart GIMP. Re-show them and lag is back. At least this is a temporary solution that makes GIMP usable again. But if you need the rulers, then you are out of luck for now.
Tested on an Asus EP121 slate (Wacom digitizer) and my main pc (Trust Aeroo) and that ruler trick runs in booth.
Created attachment 287986 [details] [review] quick hack Reading gimpruler.c there is one thing unnecessary: processing an expose event two cairo contexts are created and destroyed for the same window. Perhaps destroying them causes a flush or whatever expensive call on Windows and Osx. I tested the patch on Linux only, so perhaps it doesn't help at all.
Comment on attachment 287986 [details] [review] quick hack Massimo, why did you remove the check for gtk_widget_is_drawable() in the patch?
Created attachment 292045 [details] [review] quick hack The previous patch was wrong because the first cairo context had a translation when used in place of the second and the ticks were misplaced. Unfortunately on my Win7 64 bit GIMP does not show lags or tearing and so I cannot say whether this patch makes a significant difference.
*** Bug 738802 has been marked as a duplicate of this bug. ***
*** Bug 736057 has been marked as a duplicate of this bug. ***
*** Bug 739330 has been marked as a duplicate of this bug. ***
Does this fix it? Please try with tomorrow's nightly build from http://nightly.darkrefraction.com/gimp/ and report back. commit 8de8583064cd1586109c4a8bb3d7ce9e331e5776 Author: Massimo Valentini <mvalentini@src.gnome.org> Date: Wed Dec 3 07:44:45 2014 +0100 Bug 736411 - Ruler updates cause slowdown when painting Reuse the cairo_t from expose() in gimp_ruler_draw_pos() instead of creating a new one. (cherry picked from commit 20863440fbe754c34059ca04a042bd927fbb9d6b) libgimpwidgets/gimpruler.c | 40 +++++++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 15 deletions(-)
Michael Natterer, I tried the dev build at http://nightly.darkrefraction.com/gimp/ My ruler still dramatically slows down my brush until i hide the ruler. Not sure if the commit was reverted since 2015-01-10 because there has been no reply. Just thought I would try it out and report results because it looks like nobody else is going to. Wacom Bamboo Tablet Windows 7 x64 gimp-dev-x86_64-2015-02-23
Thanks for checking.
I have the same Problem (Windows Vista 32-bit on a notebook with integrated Intel graphics) in normal configuration (no digitizer, only regular mouse). With 2.8.10 all was fine, with 2.8.14-1 a bad lag in all drawing and selecting activities. But the ruler trick works. (Rulers off = lag off!) Same lag with 2.8.15 and 2.9 Nightly 32-bit 2015-02-27
Wacom Bamboo Tablet Windows 7 x64 gimp-dev-x86_64-2015-02-27 Intel HD 4600 Open Gimp while the tablet is disconnected: Everything is smooth as expected when rulers are present. Drawing with mouse is fine. Plug in the tablet, drawing with rulers is still smooth as expected. Open Gimp while the tablet is connected: Drawing with the tablet is very janky. Mouse is unaffected. Disable rulers and it is smooth again. Enable rulers and it is janky again.
*** Bug 743864 has been marked as a duplicate of this bug. ***
*** Bug 736220 has been marked as a duplicate of this bug. ***
(In reply to Michael Schumacher from comment #9) > This is being worked on, in particular by: > > - finding the change in libcairo that causes it (via git bisect from a known > good version to the current one > - help the libcairo developers to fix it, if possible > > > We do not want to ship current GIMP installers with old versions of > libraries. > > > Bug 736220 contains links to corresponding bugs in the libcairo bug tracker. I tried this solution a while ago but had not the wished results. The tablet works with the old libraries, but from then on GIMP starts to crash several times without warnings. Often if you haven't even done anything but one mouse click in the layer list, one point on the canvas or just tried to save. Sometimes it just stops responding, sometimes you get a message that looks like this: "Could not resolve x Bytes" (x is no fix number, it changes every time you get this.) When you close the message, GIMP crashes immediately. So the solution is to disable the rulers, right? Then I'll try this solution.
That's a workaround, not a solution. A solution would most likely be a code change - either to GIMP or Cairo - that makes the slowdown disappear while retaining all functionality of GIMP.
*** Bug 749231 has been marked as a duplicate of this bug. ***
*** Bug 743564 has been marked as a duplicate of this bug. ***
Some related links. Related inkscape bug: https://bugs.launchpad.net/inkscape/+bug/1351597 Related cairo bugs: (from bug 736220) https://bugs.freedesktop.org/show_bug.cgi?id=60496 https://bugs.freedesktop.org/show_bug.cgi?id=71833
My current theory is that this happens because we're drawing part of the widget in gimp_ruler_set_position. We should probably replace the call to gimp_ruler_draw_pos with gtk_widget_queue_draw_region or similar to invalidate the region and let gtk call expose. I suspect this is causing the issue because the inkscape bug report above contains a patch that claims this is fixed by moving the position redraws into an idle handler. Also, people seem to be reporting that this happens more with tablets, which would make sense because tablets send more events than a mouse, so we end up spending all our time redrawing the rulers with cairo for each new event.
IMO we should make this a release blocker for 2.8.16.
I'm still very concerned and monitoring this bug. As soon as I get my computer setup again (just moved) I will be able to test any builds.
Created attachment 309097 [details] [review] libgimpwidgets: Avoid drawing rulers in the position property setter. Okay. This patch is an attempt at a fix. I'll make a build of it tomorrow so people can test.
Okay here's a build with the fix included: http://tmp.darkrefraction.com/gimp-dev-i686-2015-08-12-with-ruler-fix.exe And here's an otherwise identical build without the fix, as a point of comparison: http://tmp.darkrefraction.com/gimp-dev-i686-2015-08-12-no-ruler-fix.exe I'd appreciate it if anyone who can reproduce this bug were to test these builds and see if it's fixed or not. Thanks!
In my simple tests I can confirm the fix does fix the problem. ##################################################################### gimp-dev-i686-2015-08-12-no-ruler-fix Wacom Bamboo Tablet Windows 7 x64 Intel HD 4600 Open Gimp while the tablet is disconnected: Everything is smooth as expected when rulers are present. Drawing with mouse is fine. Plug in the tablet, drawing with rulers is still smooth as expected. Open Gimp while the tablet is connected: Drawing with the tablet is very janky. Mouse is unaffected. Disable rulers and it is smooth again. Enable rulers and it is janky again. ##################################################################### gimp-dev-i686-2015-08-12-with-ruler-fix Wacom Bamboo Tablet Windows 7 x64 Intel HD 4600 Open Gimp while the tablet is disconnected: Everything is smooth as expected when rulers are present. Drawing with mouse is fine. Plug in the tablet, drawing with rulers is still smooth as expected. Open Gimp while the tablet is connected: Drawing with the tablet is smooth as expected. Mouse is unaffected. Disable rulers and it is smooth. Enable rulers and it is still smooth.
Thank You Mike, it works! Windows Vista 32-bit Pentium dual-core with integrated Intel Graphics Regular usage with mouse Compared gimp-dev-i686-2015-08-12-with-ruler-fix with actual stable (2.8.14) and the problem is solved!
Okay. Pushed to master and 2.8. Thanks to everyone for being patient and helping to fix this. commit 597fae39b4911b6e6e201e711f6de86cb6548f10 Author: Michael Henning <drawoc@darkrefraction.com> Date: Tue Aug 11 16:20:59 2015 -0400 Bug 736411 - Ruler updates cause slowdown when painting We now avoid drawing rulers in the position property setter and use gtk's region invalidation instead. Previously, we were basically redrawing the ruler inside the mouse event handler, which is pure evil. (cherry picked from commit 72617e42b426e6788c075539a20df7365d2cf102)
Wacom Intuos3 PTZ630 Windows 8 64-bit Intel Core i5-3337U @ 1.8 GHz Just another confirmation, had to set PATH to the bin directory for the dev build to run, but gimp-dev-i686-2015-08-12-with-ruler-fix fixed the laggy tablet problem for me too. Thanks!
Monoprice 9x12 Tablet PID 6815 Windows 10 Intel Core i7-4810MQ @2.8GHz Just wanted to confirm this was a fix for me in Windows 10. Been looking for a solution for a while and braved spelunking into unfamiliar territory of the debug archives. Glad I was able to find it here. Thanks for you work, Mike!
Goodness, this thread has really helped me. The slowness of the current version (2.8.14) means I've been using 2.6.9 until it's sorted. For me removing the ruler etc on 2.8.14 really helps amazingly, making it usable again, but if you compare it to the perfect smoothness of selection rectangles and crops on 2.6.9, there must still be some other lag beyond that caused by the rulers. I hope you can find it. It may be this difference between 2.6.9 and 2.8.14 is much more noticeable on slightly slower machines as mine isn't the fastest, in which case try it accordingly. I'm still on XP SP3 but hopefully that shouldn't make a difference. Cheers, david