text tool: severe performance problem in complex SVG files under linux

Based on the screenshot seems related to (or a duplicate of)
- Bug #497094 “editing of big text area (>500 characters) makes typing extremely slow”
  <https://bugs.launchpad.net/inkscape/+bug/497094>

Thanks.
Only thing is I have the problem typing the first word. Just labels on a drawing.

Can anybody advise how to play around with text settings such that they don't max out the CPU usage?

Confirmed on Windows XP, Inkscape trunk revision 12713. Not only the CPU usage is high, but memory usage also raise quickly (up to 1 GiB after some editing/zooming actions).

@shymoon - Note that you file is really big (13,5 MiB). Hiding some layers (Trees, Ground cover, Shrubs) seems to improve text editing.

Thanks for the tip!
On 23/10/2013 7:56 AM, "jazzynico" <email address hidden> wrote:

> Confirmed on Windows XP, Inkscape trunk revision 12713. Not only the CPU
> usage is high, but memory usage also raise quickly (up to 1 GiB after
> some editing/zooming actions).
>
> @shymoon - Note that you file is really big (13,5 MiB). Hiding some
> layers (Trees, Ground cover, Shrubs) seems to improve text editing.
>
> ** Changed in: inkscape
> Status: New => Confirmed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1219794
>
> Title:
> cpu spikes when writing or editing text
>
> Status in Inkscape: A Vector Drawing Tool:
> Confirmed
>
> Bug description:
> I have a i5 processor and AMD radeon graphics card (6550) which has
> propriety drivers installed. Inkscape 4.8 on Ubuntu 13.04
>
> This system seems to be able to handle most things I use Inkscape for
> (graphic design) except when I write a simple block of text, just a
> word or two as a label.
>
> Sometimes just writing labels does not slow things down too much, then
> other times it slows down to the point of 'greying out' and freezing
> completely. Perhaps it is worse when editing already written text,
> though I am not sure.
>
> I have observed that this occurs as cpu spikes on any one of 4 cores.
> As you can see by the screenshot, in which I am attempting to edit
> some simple text, the cpu is spiking to 100% but the RAM is hardly
> being used. This slows me down to the point of frustration as I use
> this software a lot (having switched from using illustrator on
> windows).
>
> I only hope there is a simple solution, perhaps to do with text
> settings? I cant imagine why simple text would use more cpu than
> shapes with gradients etc.??
>
> Cheers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/inkscape/+bug/1219794/+subscriptions
>

I tested the file in comment #4 on :

-a linux mint box 64 bits with inkscape Inkscape 0.48+devel r12934 (I see the same behavior on several machines with different distros, different inkscape versions, different video cards...)
-a (older, slower) win XP 32 bits machine with inkscape Inkscape 0.48.5 r100040 (latest available from website AFAICT)

behavior is *much* slower in linux: With the text tool, clicking on any text box one cpu core spikes to 100% until the cursor is in the new edit position. This lasts ~ 1-2 seconds in win XP and 20 seconds or more in linux. And then, once you type some text in, its also much less reactive in linux (text appearing on screen may easily lag by several characters). Seems to me that it's tracking the position of the cursor when text tool is selected that is way too slow in linux (when the svg is large).

This happens independently of the size of the text you wish to edit (it also happens for starting a new text box). Hiding other layers or the rulers does not help noticeably in linux.

So, it looks to me exactly what I reported in bug #1398032 which could make it a duplicate of this bug. However, comment #5 above most certainly missed the discrepancy between windows and linux behavior, and the severity of the problem in linux.

I attach a patch for text-tool.cpp that dramatically improves the reactivity and hence the usability of the text tool in linux. The idea is to flush the motion events that arrive while the tool is trying to figure what piece of text might be under the cursor, which takes a long time in a large drawing. BTW unless I'm mistaken it seems that this search does not take into account the visibility (or editability) of elements in the drawing.

The attached patch is obviously only a partial solution. It makes working with large files still slow, but bearable, at least.

Patch tested successfully on Crunchbang Waldorf (Debian stable based distro) with Inkscape trunk rev. 13878. Modifying text is ways faster with the patch.
However I'm not expert in that part of the Inkscape code and thus it needs to be reviewed by a developer, and tested intensively for regressions.

Thanks for your help, Philippe!

Yes thank you indeed!
I will try this out when I return home to my PC in Feb.
On 28/01/2015 9:15 PM, "jazzynico" <email address hidden> wrote:

> Patch tested successfully on Crunchbang Waldorf (Debian stable based
> distro) with Inkscape trunk rev. 13878. Modifying text is ways faster with
> the patch.
> However I'm not expert in that part of the Inkscape code and thus it needs
> to be reviewed by a developer, and tested intensively for regressions.
>
> Thanks for your help, Philippe!
>
> ** Changed in: inkscape
> Status: Confirmed => In Progress
>
> ** Changed in: inkscape
> Milestone: None => 0.92
>
> ** Changed in: inkscape
> Assignee: (unassigned) => philippe joyez (uone-5-pjoyez)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1219794
>
> Title:
> cpu spikes when editing text in complex SVG files
>
> Status in Inkscape: A Vector Drawing Tool:
> In Progress
>
> Bug description:
> I have a i5 processor and AMD radeon graphics card (6550) which has
> propriety drivers installed. Inkscape 4.8 on Ubuntu 13.04
>
> This system seems to be able to handle most things I use Inkscape for
> (graphic design) except when I write a simple block of text, just a
> word or two as a label.
>
> Sometimes just writing labels does not slow things down too much, then
> other times it slows down to the point of 'greying out' and freezing
> completely. Perhaps it is worse when editing already written text,
> though I am not sure.
>
> I have observed that this occurs as cpu spikes on any one of 4 cores.
> As you can see by the screenshot, in which I am attempting to edit
> some simple text, the cpu is spiking to 100% but the RAM is hardly
> being used. This slows me down to the point of frustration as I use
> this software a lot (having switched from using illustrator on
> windows).
>
> I only hope there is a simple solution, perhaps to do with text
> settings? I cant imagine why simple text would use more cpu than
> shapes with gradients etc.??
>
> Cheers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/inkscape/+bug/1219794/+subscriptions
>

I am unable to locate a file at

src/ui/tools/text-tool.cpp

I assume I need to edit this file in Inkscape in order to apply the patch but cannot find it or anything like it anywhere on my system. Any help?

Thanks

never mind I just found this quote:

"Patches are not meant for regular users: you would have to be able to compile the current development version of Inkscape yourself on your system (and know how to apply the patch to the sources). Keep in mind that the bug tracker is a tool for developers to track progress on fixing reported issues and discuss proposed solutions/implementations - as users, you'll get the result in bug fix releases and new major versions (for new features).

Please show some patience -.... Hopefully you'll see the result in the next major release."

In this forum:

http://www.inkscapeforum.com/viewtopic.php?f=29&t=5911

Cheers

Jazzynico, I realize you have assigned this bug to me, but I'm not exactly sure what that means or what you expect me to do based on that.

Also at the same time you say the patch should be reviewed by a developper, and I perfectly agree with that: my patch was more a quick and dirty hack meant to show where the problem is, but the problem itself probably requires a better, more elaborate fix. I am not knowledgeable enough in Inkscape code to provide the "correct fix", and, sadly, it won't happen anytime soon.

PJ> I'm not exactly sure what that means or what you expect me to do based on that.

Don't worry, It's just a way to remember that you provided a patch.
Now the it needs to be reviewed by developers before we release a new version.

Strangely this issue is solved for me (Win 7 x64) with the win32-build of r14274 by Nicolas Dufour.

OK, I tried a really large file and the issue is still there. But with smaller files it is certainly better.

I just changed the summary to stress that the slowdown problem most severely affects the linux platform. Testing on windows does show a slowdown, but it's nothing compared to linux (hence the above two comments).

I also marked bug #1398032 as a duplicate of this one.

to suv: why removing the "under linux" from the summary? Have you compared the behavior of the different platforms?

For my part I compared linux and windows and the slowdown experienced under windows is certainly noticable but by no means as severe as under linux (see https://bugs.launchpad.net/inkscape/+bug/1398032). Jazzynico also has been looking at this issue on both OSes (https://bugs.launchpad.net/inkscape/+bug/1219794/comments/5 & https://bugs.launchpad.net/inkscape/+bug/1219794/comments/9) and he could maybe confirm this.

On 2015-08-29 16:14 (+0200), Philippe Joyez wrote:
> to suv: why removing the "under linux" from the summary? Have you
> compared the behavior of the different platforms?

*shrug* - whatever. I give up on this one. Take the report, turn it into a Linux-specific one if you think it serves the project best ...

You might want to take the time to check the history of this report and all its current duplicates, and make sure that all reports _not_ about Inkscape _0.91_ on _Linux_ are unlinked and properly relinked to a more generic report (not limited to specific OS and/or Inkscape release).

Can't test at the moment because the file attached comment #4 now causes Inkscape to crash on my Xubuntu 15.04 laptop (tested with 0.91 and trunk rev. 14331, and the patch doesn't help).
I can only confirm that text changes on Windows XP take about 1-2 seconds render (no improvement with the patch). Tests planned later on my development desktop.

suv, you are right that I had overlooked that some issues listed as duplicates of this one were reported for windows, so that listing this issue as linux-only makes things inconsistent. I didn't mean to offend here, my apologies.

Let me recap the issues listed as duplicates of this one:

    Bug #497094 : Original report on windows, but Jazzynico says it's OK on windows (#2) whereas problem are indeed found on linux (#3,4)
    Bug #924657 : Original report on windows, confirmed.
    Bug #1048299 : Original report says "reproducable on LInux and windows", but it's not quantitative and no test files are provided.
    Bug #1333642 : Original report on Linux only.
    Bug #1398032 : My report pointing that linux is more severely affected than windows

and finally the present issue concerned a linux machine, and #15,#16 seem to indicate it's more or less OK on windows.

I think its definitely relevent to have at least one summary pointing the windows/linux discrepancy, either this one or #1398032 which in my view are the same issue. And then, as you point correctly one would need to unlink #924657 & #1048299 (even though I bet that for the test file provided in #924657 the slowdown will be much worse in linux than in windows). I let you decide, you have a much better overall view of the bug tracker than I have.

I my view, working with text in large files is slow on any OS, but much much slower on linux. According to the previous comment my quick-and-dirty patch makes linux coming on par with windows.

I have no idea if this feedback is valuable, but I can confirm this same bug, using Inkscape 0.91 (binary installed) on Ubuntu 14.04. The machine is pretty powerful, a Xeon E5-1650-v3 hexacore 3.5 GHz with 64GB of DDR4 memory. I am considering switching to the source version and compiling myself, to see if the patch provided in this thread helps me. I'm designing a scientific poster, which contains lots of complex vector graphics and to which I need to add a fair amount of text, this bug is making this very hard to do.

If there is anything I can do to help, let me know!

I've now compiled Inkscape (current trunk r14397) with the patch from this thread, and unfortunately it does not fix performance very much. Without the patch, while typing, characters would appear in groups of 4 or so; with the patch, the characters appear one by one, but still nowhere near as fast as should be the case (i.e., nearly instantaneously; now there is a delay of at least 500ms I guess).

@Spaak, We must be going to the same conference :-) I'm also attempting to prepare a scientific poster with Inkscape. Typing was ok to start with, but as I'm adding elements and the SVG is getting more complex typing is dramatically slowed down. I have tried moving content to layers, so that I'm typing into an empty layer while all other layers are hidden, but that does not help. There's a 1 sec delay from pressing a key and the character appearing. Moving text around is much faster.

I'm trying to find the origin on these performance problems; already found 2 :

-> _when moving the cursor around_ (in text edit mode at least, probably in other tools as well), a list of all elements was computed at each mouse move[goal: to show the right cursor]. I pushed a fix for this (caching the list) in r14655. I'm not sure what the gobble fix proposed here does (if i understand correctly it "loses" the next same events, relieving a bit the cpu from that task), it might still be useful in addition, but i don't think so.

-> _when typing_, we spend a large amount of time recomputing the ... scrollbar length.
To do that, we compute (recursively) all bboxes in the document (because we want the root bbox), which are not well cached either, all that because "potentially" the edit has made the root bbox change, so the scrollbar "may" have to change. I might look for a way to fix that, not sure how yet (prevent "modified" signals when editing text, maybe?)

-> There must be other problems

I am experiencing the same on Inkscape 0.91 r13725 on a Ubuntu 15.10, very slow text editing and CPU spikes while editing files with too many elements.

I just compiled r. 14764, and on the kind of file that was problematic in linux it is now incomparably more reactive than it used to be! It is now perfectly usable.

Good job Mc and many thanks!

Just compiled r14843 on Ubuntu, and unfortunately I am still getting the same issue.

A... G... O.. N.. I.. Z.. I.. N.. G..

Problem remains in Inkscape 0.92 and is basically a showstopper-level bug.