Inkscape + Cairo >= 1.12 very slow on Windows, unless rulers are hidden

[jazzynico]

Bug reproduced on Windows XP 32bits when testing Cairo 1.12+ versions to fix various Cairo related bugs. It affects computers with some (but not all) Intel graphic cards, which become almost unusable.

Reference inkscape-devel post: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-td4966631.html
Also mentioned in http://inkscape.13.x6.nabble.com/Status-of-Inkscape-0-91-Release-td4969769.html

The issue doesn't affect the current official devlibs used with 0.48.x and the trunk, but could be a blocker to the fix required for Bug #804162 "pixelated bitmaps on canvas and export with Cairo rendering". Thus I don't know how to manage the bug status and importance. Don't hesitate to change it to more appropriate values if needed.

[jazzynico (jazzynico)]

I'm currently updating some libraries for Inkscape on win32, and notice a serious UI slowdown when updating the Cairo libs. Everything works as expected with Cairo-1.11.2 (the dll we provide with the latest stable Inkscape version, 0.48.4), but the Inkscape UI becomes very slow when drawing or moving objects on canvas with a more recent Cairo version (tested with 1.12.0, 1.12.8, 1.12.14, 1.12.16 and yesterdays git version). I've also updated Pixman to 0.32.4, but noticed no regression with the Pixman update as long as I don't update Cairo too.
I've tried with different compilers (TDM-GCC-4.5, TDM-GCC-4.6 and TDM-GCC-4.8.1) with no difference.

Other operating systems are not affected (tested on Debian stable with Cairo-1.12.2 and Pixman-0.26, but other Inkscape users confirmed it's ok with recent Ubuntu and OS-X versions).

[jazzynico (jazzynico)]

Tested again on another computer with an nvidia GeForce 210 (GT218) and found out it is not affected (Windows XP Virtualboxed on Debian stable).
IIRC the affected computers were all running Intel graphic cards. I'm going to investigate and give details on the affected GPUs later today.

[jazzynico (jazzynico)]

I can reproduce the bug with two computers with the following graphic cards:
* Intel HD Graphics 2500 (Dell Optiplex 3010),
* Intel GMA 4500 (Dell Optiplex 780).

[jazzynico (jazzynico)]

Also reproduced with Intel 82945G Express.

NOT reproduced with
* ATI Mobility Radeon HD 4500 Series;
* NVidia Quadro 1000M;
* NVIDIA GeForce GTX 660 Ti;
* Intel HD 3000 (integrated).

See the Inkscape-devel mailing list thread for details (http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-tt4966631.html#none).

[Alvin Penner (apenner)]

just copying a comment from: http://inkscape.13.x6.nabble.com/Devlibs-46-too-slow-td4966631i20.html#a4971098

I just downloaded your file : inkscape-12282-cairo-1.12.8.7z from April 19, 2013.

It runs fine for me, with just one rectangle with a radial gradient and very fast dragging, 2 Windows machines.

Windows XP, CPU: Intel 2.2GHz, Display: Mobile Intel 965 Express Chipset
when dragging, Inkscape used 50% of CPU time, at rest it used 0%

Windows 7 (32 bit), CPU: Pentium 3.2GHz, Display: Intel G41 Express Chipset
when dragging, Inkscape used 40% of CPU time, at rest it used 0%

[jazzynico (jazzynico)]

LucaDC first reported the slowdown with an Intel 82945G Express graphic card.

I'm wondering if it could be due to the device drivers...

[B-harrington (b-harrington)]

1.12.0 was released March 23, 2012, so if the performance was due to changes to cairo, it would show up in the changelog for prior to this period.

And in fact I notice that in Feb/Mar of that year there was a considerable amount of work done in src/win32 when the win32 code was split out and rebased to the new compositor infrastructure. I don't see any noteworthy perfomance work done in win32 subsequent to March 23rd. So, guessing maybe there was some unfinished performance work, at least for certain breeds of hardware?

[su_v (suv-lp)]

@JazzyNico - just wondering, does hiding the ruler in Inkscape have any affect on the performance on affected computers?

(Recent Windows builds of GIMP with newer cairo version also seem to be affected by performance issues related to cairo - GIMP users noticed that hiding the ruler improves performance. AFAIK Inkscape's ruler widget is based on code from GIMP. If the ruler updates contribute to the performance issues tracked here, maybe this recent commit in GIMP could be ported and tested with Inkscape:
<https://git.gnome.org/browse/gimp/commit/?id=20863440fbe754c34059ca04a042bd927fbb9d6b>)

[jazzynico (jazzynico)]

@~suv - Thanks for the link! I'll try to test your tip the next time I have access to an affected computer (maybe later today).

[jazzynico (jazzynico)]

@~suv - Good catch! I've tried with an old rev. 12282 with Cairo 1.12.8, and disabling the ruler fixes the issue.
Thanks you (and Gimp).

[Louis Simons (lousimons)]

Confirming that hiding the ruler causes significant improvement on Windows 7 x64 with Inkscape 0.91pre4. Dragging the workspace stutters with rulers enabled and is fluid with them hidden.

[Ellipsis (ellipsis)]

I can confirm that hiding the ruler fixes a performance issue on Inkscape 0.91 r13725 on Windows 8.1.
Thanks to suv/su_v and the rest of the people on IRC for pointing this out. It appears to be getting quite a bit of attention.

[Sadid (sadid-shadow)]

this might not be related but just the same issue (very slow performance on calligraphy, pen or text box.
https://answers.launchpad.net/inkscape/+question/261949

[Alvin Wong (alvinhochun)]

I have a possible way to fix this bug.

What I noticed is that Inkscape queues redraws to the canvas by using `gdk_threads_add_idle_full` at `src/display/sp-canvas.cpp:2332`, in contrast, `sp_ruler_draw_pos` in `src/widgets/ruler.cpp` is called directly from within the mouse signal handler.

This patch changes `sp_ruler_draw_pos` to be called by queuing the function with `gdk_threads_add_idle_full`.

Tested this with 0.91 64-bit under Windows 7, with Intel HD Graphics 4000

This patch, however, causes another minor rendering bug when dragging the drawing area around very quickly. I guess this has something to do with priorities also.

[Alvin Wong (alvinhochun)]

Attached is the patch against trunk

[Alvin Wong (alvinhochun)]

One thing though, I mainly tested drawing with the Bezier tool.

Also, I have no idea how this fix is related to cairo at all.

[Liam P. White (liampwhite)]

GTK+ developers feel it is abhorrent to draw outside of the expose/draw handler (yes, we do this in the canvas, and it's bad; and doing this doesn't work correctly in GTK+ 3.0), so I cannot recommend this patch.

[su_v (suv-lp)]

On 2015-01-11 22:27 (+0200), ~suv wrote:
> (Recent Windows builds of GIMP with newer cairo version also seem to
> be affected by performance issues related to cairo - GIMP users
> noticed that hiding the ruler improves performance. AFAIK Inkscape's
> ruler widget is based on code from GIMP. If the ruler updates
> contribute to the performance issues tracked here, maybe this recent
> commit in GIMP could be ported and tested with Inkscape:
> <https://git.gnome.org/browse/gimp/commit/?id=20863440fbe754c34059ca04a042bd927fbb9d6b>)

The mentioned GIMP commit had been backported to inkscape trunk by Liam P. White on 2015-02-25:
* Revision 13941: Backport commit 2086344 from GIMP master: try to fix rulers (bug #1351597)
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13941

Today a final fix for the same issue was committed in GIMP:
* https://bugzilla.gnome.org/show_bug.cgi?id=736411#c39
* diff in GIMP master:
https://git.gnome.org/browse/gimp/commit/?id=72617e42b426e6788c075539a20df7365d2cf102

Anyone willing/able to investigate this second commit in GIMP to address ruler performance issues on Windows for backporting to Inkscape trunk too (the second commit in GIMP is on top of the first one, it removes most of the changes the first one had added), and to offer patched 64bit Inkscape builds for Windows (with cairo 1.14) for testing?

[su_v (suv-lp)]

On 2015-08-13 19:35 (+0200), ~suv wrote:
> Today a final fix for the same issue was committed in GIMP:
> (...)

It was not yet the final fix after all; due to a regression the last commit introduced on Linux, there are two more follow-up commits also to be considered for backporting to Inkscape. Please see this gist for details:
* https://gist.github.com/su-v/962457125be511b054d0

Direct links to the commits:
* https://git.gnome.org/browse/gimp/commit/?id=3233a70bae756e8f62fb144cbce9d8f84ed25609
* https://git.gnome.org/browse/gimp/commit/?id=8c02b360fb1a69d68b8c4cb2b1c5f7820c3f1640

[jazzynico (jazzynico)]

Patch tested on Windows XP, Inkscape trunk rev. 14630, Cairo 1.14.6.
Inkscape is no longer slow, but I didn't test the ruler extensively for regressions yet.

Windows testers are more than welcome!

[jazzynico (jazzynico)]

Test binary available: ftp://download.tuxfamily.org/inkscape/inkscape-14630-Cairo-1.14.6+patch.7z

[Patrick Storz (ede123)]

Good news:
I just created a patch that combines the four relevant GIMP commits [1-4].

It solves the issue for me on Windows 7 using the latest devlibs64 (gcc 5.3 branch [5]), i.e. cairo 1.15.2.

Testers are welcome, especially to check if this causes any regressions I did not notice.

[1] https://git.gnome.org/browse/gimp/commit/?id=72617e42b426e6788c075539a20df7365d2cf102
[2] https://git.gnome.org/browse/gimp/commit/?id=3233a70bae756e8f62fb144cbce9d8f84ed25609
[3] https://git.gnome.org/browse/gimp/commit/?id=8c02b360fb1a69d68b8c4cb2b1c5f7820c3f1640
[4] https://git.gnome.org/browse/gimp/commit/?id=f6df75071467cb84813c346e3729dd80723d3a2b

[5] https://code.launchpad.net/~inkscape.dev/inkscape-devlibs64/5.3

[Patrick Storz (ede123)]

Ah crap! What are the chances? I'm just seeing Nicolas's fix from just an hour ago...
No activity for five months and then two fixes in just under an hour.

[jazzynico (jazzynico)]

@Eduard - My patch doesn't include the very last commits in the gimp code, and therefore probably misses some fixes or optimizations. I'm going to test yours so that we could fix the issue (and possibly push the new Pixman/Cairo versions in the win32 devlibs).

[jazzynico (jazzynico)]

@Eduard - I had to modify your patch because it didn't compile with the current win32 devlibs. The G-SOURCE-REMOVE macro was added in glib-2.32, but we still use glib-2.28 (and I don't really want to update it now...). See https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#G-SOURCE-REMOVE:CAPS

So I used the old g_source_remove() function instead (hope I used it correctly...) and it compiled and worked as expected.

New patch (based on Eduard's, comment #22) attached.

[jazzynico (jazzynico)]

@Testers, the patch fixes thinks for Windows, but could affect other systems and gtk versions. Could you please test it on Gnu/Linux and OS-X, with Gtk2 and Gtk3 builds? Thanks!

[su_v (suv-lp)]

On 2016-02-14 10:57 (+0100), jazzynico wrote:
> Could you please test it on (…) OS-X, with Gtk2 and Gtk3 builds?

Patch tested sucessfully (no obvious regressions noticed) on OS X 10.7.5
with Inkscape 0.91+devel r14648:
- GTK+/X11 2.24.13, gtkmm 2.24.2, GLib 2.32.4, glibmm 2.32.1
- GTK+/X11 2.24.29, gtkmm 2.24.4, GLib 2.46.2, glibmm 2.44.0
- GTK+/X11 3.18.6, gtkmm 3.16.0, GLib 2.46.2, glibmm 2.44.0
- GTK+/Quartz 2.24.29, gtkmm 2.24.4, GLib 2.46.2, glibmm 2.44.0
- GTK+/Quartz 3.18.6, gtkmm 3.16.0, GLib 2.46.2, glibmm 2.44.0

Tests are limited though (I did not test with Wacom tablet (Bamboo
CTH-470); a small screen (13-inch) might not expose issues observed in
fullscreen mode on large monitors).

There are a few compiler warnings (3 with llvm-gcc-4.2, FSF GCC 4.6.3; 1
with clang) about "missing-field-initializers" in
sp_ruler_get_pos_rect(), but those could well be false positives with
outdated compilers, idk.

[jazzynico (jazzynico)]

~suv> There are a few compiler warnings

Confirmed on Xubuntu 15.10, with gcc-5.2.

With GTK2, the ruler is noticeably larger (see screenshot). I didn't see the same change with Windows XP.

[su_v (suv-lp)]

@JazzyNico - AFAIU the "larger" rulers in trunk are due to the new toggle icon to lock guides (rev >= 14512), not to the patch.

[jazzynico (jazzynico)]

Patch also tested successfully with GTK3 and a Wacom Bamboo tablet, on Xubuntu 15.10, and committed in the trunk rev. 14670.
Assigning to Eduard as author of the patch (many thanks!).

[jazzynico (jazzynico)]

Still needs to be tested with the 0.91.x branch.

[Patrick Storz (ede123)]

Verified working also in 0.91 branch.
(Tested on Windows 7 x64, Inkscape 0.91 r13857 built with updated devlibs64 gcc 5.3 branch)

See patch attached.

[jazzynico (jazzynico)]

Fix applied to the 0.91.x branch rev. 13858.
Cairo and Pixman updated in the official win32 devlibs rev. 61.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/37.