Text editing very slow in 0.91 on files with many objects, normal in 0.48

[Cosmin Saveanu]

Tested with Inkscape stable 0.91 r13725 on both Mac OS X Yosemite 10.10.5 and Windows 8.1, both 64 bit.

I'm using Inkscape to build figures for scientific manuscripts and a frequent occurence is files that are around 1-2 Mb in size because there are hundreds or thousands of identical objects (dots for a scatterplot, see attached file for a test case). Two versions of Inkscape behave very differently:

0.48.5 r10040 works as expected
0.91 r13725 performance begins to degrade with increasing numbers of objects in the file, with a pause between clicking for text editing and a visible effect on screen. In the end, this version is not usable any more for editing pictures containing scatterplots.

I also tested the last development version 0.91 r14326 custom and it behaves like the stable 0.91.

The main problem and easiest to reproduce is slow text adding and editing. However, selection of objects and movement also show a very large latency. Steps to reproduce:

1. Open attached file
2. Try to add new text. First letter appears in 1-3 seconds after typing it, and the next appear after various latencies.

The same file opened in 0.48.5 can be edited, with new added text appearing as expected, almost as soon as it is typed.

This bug is very troublesome since I have dozens of figures done with older versions of Inkscape that cannot be edited any more with the newest version.

Possibly related with https://bugs.launchpad.net/inkscape/+bug/1481479 (copy-pasted my comment on that bug, with some additions).

[jazzynico (jazzynico)]

Confirmed on Windows XP (32bit) with trunk rev. 14332. Works correctly with 0.48.5.

[su_v (suv-lp)]

Could you please also test with default (new) preferences, and attach the old preferences file if this affects performance of the text tool in 0.91 and 0.91+devel (ignore 0.48 for now)?

Steps:
1) quit all running instances of Inkscape
2) rename or move the existing preferences file
 ~/.config/inkscape/preferences.xml
3) launch inkscape again
4) repeat same tests

[su_v (suv-lp)]

Maybe you could also test the attached modified test case (simplified structure only - the amount of objects (dots) is the same) wrt performance of the text tool in 0.91/0.91+devel on your system (with current as well as with default prefs).

--
Sorry for the long file name - it helps to keep track of changes when attempting to construct a reduced test case.

[su_v (suv-lp)]

On 2015-09-02 09:53 (+0200), ~suv wrote:
> Could you please also test with default (new) preferences (…)

The reason behind this question: with local tests, I notice much worse performance with >= 0.91 if the 'Text and Font' dialog has been opened at least once in the current session (e.g. because its dialog state was restored from last session). I'd be interested in whether this is a local symptom only or reproduces on other systems too (test editing text with new prefs and just the text tool on-canvas (without opening 'Text and Font')).

[jazzynico (jazzynico)]

Regarding comment #3, rev. 14332 is still slow with a default preferences file.
Regarding comment #4, the text tool is by far faster with the modified test case than with the original one.

I've also tested with older revisions available on my computer, and the regression seems to happen somewhere between rev. 13273 and 13534.

[su_v (suv-lp)]

On 2015-09-02 10:39 (+0200), jazzynico wrote:
> I've also tested with older revisions available on my computer, and
> the regression seems to happen somewhere between rev. 13273 and
> 13534.

Tests with locally archived builds in two independent build setups (different versions of the dependencies) within that range confirm a regression related to the changes in r13401:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13401

[su_v (suv-lp)]

On 2015-09-02 11:04 (+0200), ~suv wrote:
> Tests with locally archived builds (…) within that range confirm a
> regression related to the changes in r13401

Tests had been done with default (new) prefs and the original test case.

Details:
- rev <= 13400: performance ~ok (more sluggish than with 0.48 though)
- rev >= 13401: noticeably worse performance compared to 13400

[jazzynico (jazzynico)]

On 2015-09-02 11:04 (+0200), ~suv wrote:
> Tests with locally archived builds (…) within that range confirm a
> regression related to the changes in r13401

Confirmed. Commenting line 299 in src/libnrtype/font-lister.cpp improves performance (not a proper fix though...).

[su_v (suv-lp)]

On 2015-09-02 10:39 (+0200), jazzynico wrote:
> Regarding comment #4, the text tool is by far faster with the
> modified test case than with the original one.

Could you test the two attached files wrt performance differences (e.g.
with r13534 or whatever build you have available which is closest to
r13401)?

* 1491064-plot-clones-unlinked-0485.svgz: symbol instances of the dots
are unlinked (the paths for the dots are inside two nested group levels,
one setting fill style, one with a preserved 'translate()' transform)

* 1491064-plot-clones-unlinked-ungrouped-0485.svgz: all groups wrapping
the dots have been ungrouped: any preserved transforms are optimized
into the path data of the dots, the fill properties are merged into the
style of the path elements.

[jazzynico (jazzynico)]

Tested again with rev. 13534 with the following steps:
1. Keep a key pressed for 10 seconds.
2. Count how many characters show.
3. Count how long it takes to write a sequence of characters (I see a delay before the first character, and the same delay between flows of 1 to 5 characters).

> big_test_file_bug_inkscape091.svg (original file)

35 characters, 1 second delay.

> 1491064-plot-clones-unlinked-0485.svgz

35 characters, but 0.5 second delay (the buffer only outputs two times less characters each time).

> 1491064-plot-clones-unlinked-ungrouped-0485.svgz

As fast as your modified test file from comment #4, that is 120 characters, acceptable delay (maybe 0.1 or 0.2 second).

To be compared with the 200 characters (almost unnoticeable delay) we had with 0.48.5.

[jazzynico (jazzynico)]

> To be compared with the 200 characters (almost unnoticeable delay) we had with 0.48.5.

About the same when commenting the push_back line in the font lister with rev. 14332.

[Cosmin Saveanu (csaveanu)]

Resetting preferences did not change the performance of 0.91.
One more observation - deleting characters has a similar latency with adding them.

[VascoT (vasco-w)]

Is there any activity on solving this bug? At this moment I cannot finish my poster. I will try to downgrade to inkscape 0.48 in the meantime.

[AG (g-ubuntu-2)]

I can confirm this issue in Inkscape 0.91 running on Windows 10 64bit on a NUC5i7RYH. File size is 4.43MB and editing text takes forever. Previous inkscape version works fine.

[Cosmin Saveanu (csaveanu)]

This bug is related with:

- https://bugs.launchpad.net/inkscape/+bug/1359450 ("typing is super slow");
- https://bugs.launchpad.net/inkscape/+bug/1219794 ("text tool: severe performance problem in complex SVG files under linux");
- https://bugs.launchpad.net/inkscape/+bug/1481479 ("Inkscape 0.91 much slower than 0.48.5 with larger files")

Please, please - could anyone provide a workaround to be able to work on complex SVG files, until the problem gets solved in Inkscape ? Until now, I could go back to 0.48.5, but I'm now exclusively using a Linux machine and it is impossible to install earlier versions of Inkscape (compiling of 0.48.5 fails on Ubuntu 17.04 due to development libraries changes). Thank you.

[Cosmin Saveanu (csaveanu)]

Forgot to mention that my latest test, showing the same behaviour, was done with Inkscape 0.92.1 r15371 on a Ubuntu 17.04 install.

[Cosmin Saveanu (csaveanu)]

A working solution with the current version of Inkscape (0.92) is to inactivate the complex part of the drawing by:

1. putting it on a separate layer.
2. locking the layer.
3. working with text in another, separate layer

This way, I could edit misbehaving SVG files (mostly generated by R, ggplot2 ggsave) in Inkscape.

[Jonathan Polak (jpolak)]

Problem still present in 0.92 editing PDFs with lots of objects... Fix is as described by @Cosmin

[xeli (akseli-palen)]

Problem is still alive in 0.92. Reporting from OS X El Capitan 10.11.6 on Mac Mini 2012. @Cosmic's fix does not help. All other layers are hidden and locked, and still, editing text is slow as a pinecone in a pudding. Uses 80%-100% of CPU.

It feels like text manipulation somehow executes a search on all other objects for each user gesture, even for the objects on hidden layers. Could there be an accidental O(n) algorithm in the code, written especially after 0.48?

[xeli (akseli-palen)]

More findings to my previous post #20. If I restart the OS X and reopen my SVG, the slugginess seems to vanish. However, as soon as I change font settings with Text and Font panel, selecting and editing text slows down to unusable delay and is *not* improved by closing the panel. As a further note, my SVG contains over 4000 text elements.

Reflecting on this, it feels like the Text and Font panel starts some process or establishes some event bindings and fails to destroy them when the panel is closed.

[nvmd (nvmd)]

Confirming that this issue is present in 0.92.2 on my Windows 8.1 system. I am running an Intel i7-8700K, 16GB RAM, and GeForce GTX 1060 video card, and still having many text characters in one SVG renders it nearly unusable.

My current file contains about 2,000 characters across about 100 text selections, and text entry takes about 0.5 seconds per character. Additionally moving all other elements in the file also takes noticeably longer. I have experienced this identical issue in files with both more or fewer text elements, and as I use Inkscape to design interface panels and instructional infographics this problem is something I run into very frequently.

[Mister Twister (vspambox-ubuntuone)]

For me, this issue is gone with 0.92.3 on Windows 7!

[Patrick Bradley (patrick-bradley)]

Unfortunately still having this issue with 0.92.3 on Ubuntu.

[Shawn Hood (manwithfishhead)]

Problem remains in Inkscape 0.92.3 and is a showstopper-level bug. Creating scientific posters is not technically impossible, just suicide-inducing!

Restarting software has no effect, nor rebooting.

Two colleagues at the University have finally given up and moved over to Illustrator.. they will be missed :`<

[Adam McCaughan (amccaugh)]

I have this same issue, and I have found that it is exactly related to what su_v pointed out previously. To recreate the issue:

1) Set up Inkscape so that when it's launched the Text and Font dialog/panel is NOT open (e.g. close the Text and Font dialog before closing)
2) Close Inkscape
3) Open Inkscape and load a large SVG with lots of elements
4) Create a new text element and start typing -> Result: Typing is fast
5) Now, openthe Text and Font dialog/panel (Shift+Ctrl+T)
6) Create another text element and start typing -> Result: Typing is incredibly slow

Hopefully that's helpful

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael McLaren (m-mclaren42)]

My workaround for making scientific posters is to use different layers for different parts of the poster, and to lock all layers except for the part of the poster I'm currently editing text in. This seems to deal with most of the slow-down when using no layers, but is does make editing more difficult due to the need to continually lock and unlock layers. (Using Inkscape 0.92 on Archlinux, but have experienced this problem with previous versions of Inkscape for years).

[Cosmin Saveanu (csaveanu)]

The only reason I cannot recommend Inkscape as a replacement for Adobe Illustrator for scientific figures and posters is this bug, now 4 years old. Even the solution of locking the offending objects on different layers does not work all the time. With many objects, Inkscape (0.92.4 on Ubuntu 18.04), is unable to perform the move to a new layer.

I searched for alternatives to Inkscape and none of the ones that are open source is able to import correctly the svg files generated from R.

The only solution I currently have is to raterize part of the plots and use the uneditable bitmaps in Inkscape.

[Cosmin Saveanu (csaveanu)]

For Linux users who will have difficulties in downgrading to Inkscape 0.48, you can install the Windows version with PlayOnLinux/Wine:
https://inkscape.org/fr/release/inkscape-0.48.5/windows/32-bit/exe/dl/
Files impossible to open with 0.92 work perfectly well with this 0.48.5 build.

[amoeba (amoeba)]

I have exactly the same problem when preparing scientific posters and including scatter plots with thousands of points. This bug is really awful. It's been four years, it's bizarre that this hasn't been solved yet.

[Marvin J. (marvin-jens)]

I have the same issue with inkscape 1.0beta1 (fe3e306, 2019-09-17) installed via snap on Ubuntu 18.04.
But I noticed something potentially interesting though: for me, the *slowdown only happens when the mouse cursor is inside the inkscape window*.

Steps to reproduce:

1) Load a sufficiently complex file that displays slow text editing.
2) hit F1 (selection tool) and click on a text element
3) move the mouse cursor *outside the inkscape window*
4) hit F8 (text tool) and edit the text element via keyboard only (it's very fast for me)
5) hit F1 again
6) move mouse cursor back into inkscape window

This procedure makes text editing quite fast again. The slowdown is recovered if step 3) is omitted.
Perhaps this can help to point towards the cause, maybe something with updating the mouse cursor style (from arrow to text-cursor) is inadvertantly checking for potential overlap with *all* text elements?

Just my 2 cents. Hope this helps in nailing this bug down. It is a real show-stopper (also using Inkscape for scientific figures and posters)

[Marvin J. (marvin-jens)]

lacking any experience with GTK, I had a quick peek at the source and noticed that the text-tool calls sp_event_context_update_cursor in the input event processing quite a bit, whereas select-tool does not do that. Instead, select-tool calls gdk_window_set_cursor(window,...) in the GDK_ENTER_NOTIFY and GDK_LEAVE_NOTIFY events (which are not handled by text-tool at all).

Sorry if I am sending people on a goose-chase here. I just found this mouse-in-window dependency of the slow-down very curious!

[Laszlo Barna (mandruc)]

I have the same issue with inkscape 0.91 on Linux Mint 18.3 Sylvia. Thanks for Marvin's workaround #33. You saved my life. A bit elaborate for first but still worth.

[Yuan Xue (xuesoso)]

Can confirm that Marvin J. (marvin-jens)'s proposal is a temporary workaround. This issue is persistent in Inkscape beta 1.0.2 and renders the tool unusable on complex illustration (e.g. most scientific illustration).

[Nspiller (nspiller1)]

Confirmed again (as #30) for 0.92.4 on Ubuntu 18.04.

The workaround shown by #5 and #26 is to have the 'Text and Font...' box closed all the time – even at startup. You can at least use the tools in top menu bar.

I am just mentioning this again in case it got lost in the discussion.

[Luan Carvalho Martins (luancarvalho)]

This nearly five years old awful bug is still present in Inkscape 1.0 (1.0+r73+1). This is a show-stopper and render Inkscape useless for scientific use. Too bad. I am currently using Boxy SVG (https://boxy-svg.com), which is worse than Inkscape in all matters, but works for complex files. IIf you, like me, is here because you are in the brink of a crack down after hours of

[Adam McCaughan (amccaugh)]

For anyone still interested in this, I've contributed a bounty for this bug.

https://www.bountysource.com/issues/26531768-text-editing-very-slow-in-0-91-on-files-with-many-objects-normal-in-0-48

A solution would be pretty game-changing for me (for making scientific posters), and I imagine several other people as well. If it affects anyone else please consider contributing a small amount -- it could help encourage one of the developers to spend some time on it.

[MAYERE Chloé (chloefougere)]

Hi,

Bug confirmed here (Ubuntu 20.04, inkscape 0.92). Exactly same conditions. Moslty with graphics issued from python's matplotlib or R's ggplot2.
It's really annoying and sad...
Any new's about a possible resolution of the bug ?

[Jabiertxof (jabiertxof)]

Hi MAYRE Inkscape launchpad is now in read mode.

Please test with current version (1.0.2) and report bugs here https://inkscape.org/report

Regards.