Virtual memory usage spikes unreasonably high when zooming into more than one layer

[Kristin Zuvich]

Whenever I zoom into a project that has more than one layer, my available virtual memory instantly drops and becomes nearly non-existent. It takes up all my available memory and CPU, thus making the program crawl like a snail. Something even as simple as select a singular node while zoomed in often takes up to two minutes--sometimes even up to ten minutes. In fact, the very act of zooming can sometimes take up to ten minutes. A project that should have taken me a couple weeks has consequently taken me nearly a month and a half because of this bug. As soon as I close the project or zoom out, my available memory returns to normal and I can do anything else I need to do at that point (and I have plenty of available memory normally). I have tested everything by closing all other programs and have isolated the problem to this specific program (Inkscape) and the act of zooming with multiple layers. I have a Macbook Pro using OSX I would greatly appreciate if you fixed this bug, or else I will have to go buy Adobe Illustrator instead.

[ScislaC (scislac)]

Hopefully 0.49 will have these issues resolved for you. Last summer a student replaced our older renderer with one that has much better performance. Additionally, this summer he is planning on working on additional enhancements such as rendering the on-canvas controls to a different layer. This way things like the node selection should not get bogged down. Unfortunately we don't have a timeframe for 0.49 at the moment, but I'm hopeful it will be 4th quarter of this year (again, not official, just my hopes).

[Kristin Zuvich (kristin-zuvich)]

Wow! Thank you so much for the personal response. I was not actually
expecting anyone to answer. And that's very encouraging that you guys are
working on this bug--and even more so that you actually read the bug reports
and respond. There are so many companies out that would never even bother.
Have a great night--and again, thank you!!!

Kristin

--------
*Kristin Zuvich*
*Cell:* 203-232-1513
*E-mail:* <email address hidden>

*CONFIDENTIALITY NOTICE* This e-mail message is intended only for the
person(s) or organization(s) to whom or which it is addressed and may
contain information which is confidential and privileged. The unauthorized
use, copying, distribution, or disclosure of this e-mail or any of its
contents by anyone other than the intended recipient is unauthorized and
unlawful. If you have received this e-mail in error, please notify the
sender immediately and destroy all copies of this transmission. Thank you.

On Mon, May 23, 2011 at 7:57 PM, ScislaC <email address hidden> wrote:

> Hopefully 0.49 will have these issues resolved for you. Last summer a
> student replaced our older renderer with one that has much better
> performance. Additionally, this summer he is planning on working on
> additional enhancements such as rendering the on-canvas controls to a
> different layer. This way things like the node selection should not get
> bogged down. Unfortunately we don't have a timeframe for 0.49 at the
> moment, but I'm hopeful it will be 4th quarter of this year (again, not
> official, just my hopes).
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/787260
>
> Title:
> Virtual memory usage spikes unreasonably high when zooming into more
> than one layer
>
> Status in Inkscape: A Vector Drawing Tool:
> New
>
> Bug description:
> Whenever I zoom into a project that has more than one layer, my
> available virtual memory instantly drops and becomes nearly non-
> existent. It takes up all my available memory and CPU, thus making the
> program crawl like a snail. Something even as simple as select a
> singular node while zoomed in often takes up to two minutes--sometimes
> even up to ten minutes. In fact, the very act of zooming can sometimes
> take up to ten minutes. A project that should have taken me a couple
> weeks has consequently taken me nearly a month and a half because of
> this bug. As soon as I close the project or zoom out, my available
> memory returns to normal and I can do anything else I need to do at
> that point (and I have plenty of available memory normally). I have
> tested everything by closing all other programs and have isolated the
> problem to this specific program (Inkscape) and the act of zooming
> with multiple layers. I have a Macbook Pro using OSX I would greatly
> appreciate if you fixed this bug, or else I will have to go buy Adobe
> Illustrator instead.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/inkscape/+bug/787260/+subscribe
>

[su_v (suv-lp)]

Which version of Mac OS X, X11 and Inkscape do you have installed?
If possible, please attach a sample SVG drawing and a list of 'steps to reproduce' to allow further investigation of the issue on other systems and with different inkscape builds.

(More often such performance/memory issues are related to the rendering of SVG filter effects (simple blurs or complex predefined ones), not the number of layers. OTOH there exists a known memory leak when toggling the visibility of layers which contain embedded bitmap images, another one when zooming in while some paths in the document use pattern fills. But from your description the problem could well be limited limited to the node tool context when working with large paths with a huge number of nodes. Thus having an example document would be helpful for bug triage).

[Kristin Zuvich (kristin-zuvich)]

I have Mac OS X 10.6.7 and I have Inkscape *0.48.1 *installed. I can't
include the .SVG file I'm working on, as it's a project as it's a project
not meant to be released to the public until this summer. However, I can
confirm that my project does contain embedded bitmap images (they aren't
meant to show up in the final product. They just live on layers that I
usually keep invisible and only toggle to be visible when I need to use them
as reference) AND does use multiple pattern effects, including simple blurs
and the "roughen" effect. Looks as though I've got all the odds against me
with my project!

Is there a way I can get around the memory leak, other than not using
pattern fills? I will try removing the bitmaps and seeing if that helps free
up some memory.

Kristin

--------
*Kristin Zuvich*
*Cell:* 203-232-1513
*E-mail:* <email address hidden>

*CONFIDENTIALITY NOTICE* This e-mail message is intended only for the
person(s) or organization(s) to whom or which it is addressed and may
contain information which is confidential and privileged. The unauthorized
use, copying, distribution, or disclosure of this e-mail or any of its
contents by anyone other than the intended recipient is unauthorized and
unlawful. If you have received this e-mail in error, please notify the
sender immediately and destroy all copies of this transmission. Thank you.

On Tue, May 24, 2011 at 2:34 AM, ~suv <email address hidden> wrote:

> Which version of Mac OS X, X11 and Inkscape do you have installed?
> If possible, please attach a sample SVG drawing and a list of 'steps to
> reproduce' to allow further investigation of the issue on other systems and
> with different inkscape builds.
>
> (More often such performance/memory issues are related to the rendering
> of SVG filter effects (simple blurs or complex predefined ones), not the
> number of layers. OTOH there exists a known memory leak when toggling
> the visibility of layers which contain embedded bitmap images, another
> one when zooming in while some paths in the document use pattern fills.
> But from your description the problem could well be limited limited to
> the node tool context when working with large paths with a huge number
> of nodes. Thus having an example document would be helpful for bug
> triage).
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/787260
>
> Title:
> Virtual memory usage spikes unreasonably high when zooming into more
> than one layer
>
> Status in Inkscape: A Vector Drawing Tool:
> New
>
> Bug description:
> Whenever I zoom into a project that has more than one layer, my
> available virtual memory instantly drops and becomes nearly non-
> existent. It takes up all my available memory and CPU, thus making the
> program crawl like a snail. Something even as simple as select a
> singular node while zoomed in often takes up to two minutes--sometimes
> even up to ten minutes. In fact, the very act of zooming can sometimes
> take up to ten minutes. A project that should have taken me a couple
> weeks has consequently taken me nearly a month and a half because of
> this bug. As soon as ...

[su_v (suv-lp)]

1) Can you test if zooming in while in 'No Filters' display mode (see menu 'View > Display mode') still causes such performance issues?

If performance is better (and the memory usage doesn't spike as much as with 'Normal' view) it would indicate that the renderer itself is the main cause - a solution will be available in the next major release (0.49) as described by ScislaC. In the mean-time - while using current stable 0.48.1 - consider toggling off the rendering of SVG filter effects (Blurs, all filter effects from the menu 'Filters' - preset or manually added in the filter editor) before zooming in very closely.

If you mainly use Gaussian blurs, it might be worth-while to test a current development snapshot build for Mac OS X [1]. The formula for the rendering of Gaussian blurs was recently improved for better performance and might show a noticeable difference while still using the same renderer as current stable versions. Note though that development builds are usually not recommended to be used in a productive environment [2].

2) memory leak with embedded images: refers to
Bug #597689 “Memory leak when showing/hiding embedded images.”
<https://bugs.launchpad.net/inkscape/+bug/597689>
While this can contribute to increased memory usage, it doesn't cause a sudden spike as you originally described. As far as I remember from a few tests, it is not triggered by linked bitmap images (when importing you can choose between link or embed, and later on you can embed or extract images with 'Extensions > Images…').

3) memory leak with pattern-filled objects: refers to
Bug #608944 “Enormous memory consumption (memory leak?)”
<https://bugs.launchpad.net/inkscape/+bug/608944>
For this issue, unfortunately there is no known workaround to this date.

[1] <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/36273>

[2] You can download a DMG from <http://inkscape.modevia.com/macosx-snap/?C=M;O=D> and install it without deleting the stable version (install the development version into a different folder, and optionally rename it - e.g. Inkscape-rXXXXX - so that you know which version to launch).

[Kristin Zuvich (kristin-zuvich)]

Hi!

1) I tried View > No Filters, and that honestly made zooming and working on
nodes so much faster--significantly faster! I'll definitely continue doing
that, and if a massive memory leak problem comes up again, I'll let you
know.

2) I'll just link all my images, then (I usually link half of them anyway).
Thanks!

3) For blurring, I use the blur function that's in the "Fill and Stroke"
window, rather than the blurs that are found on the "Filters" and
"Extensions" menus, so I'm not sure if that's the same thing as "Gaussion
blur."

4) I don't think I use the pattern fill really. I mainly use the gradient
fill, so the pattern fill bug probably won't affect me much.

5) Is Inkscape planning to work on finding a way to allow using keyboard
shortcuts. Even just having ctrl+c and ctrl+v functions work in the program
would make my sessions twice as productive.

6) Thank you all for your prompt, detailed and helpful responses!

Kristin

--------
*Kristin Zuvich*
*Cell:* 203-232-1513
*E-mail:* <email address hidden>

*CONFIDENTIALITY NOTICE* This e-mail message is intended only for the
person(s) or organization(s) to whom or which it is addressed and may
contain information which is confidential and privileged. The unauthorized
use, copying, distribution, or disclosure of this e-mail or any of its
contents by anyone other than the intended recipient is unauthorized and
unlawful. If you have received this e-mail in error, please notify the
sender immediately and destroy all copies of this transmission. Thank you.

On Tue, May 24, 2011 at 5:34 PM, ~suv <email address hidden> wrote:

> 1) Can you test if zooming in while in 'No Filters' display mode (see
> menu 'View > Display mode') still causes such performance issues?
>
> If performance is better (and the memory usage doesn't spike as much as
> with 'Normal' view) it would indicate that the renderer itself is the
> main cause - a solution will be available in the next major release
> (0.49) as described by ScislaC. In the mean-time - while using current
> stable 0.48.1 - consider toggling off the rendering of SVG filter
> effects (Blurs, all filter effects from the menu 'Filters' - preset or
> manually added in the filter editor) before zooming in very closely.
>
> If you mainly use Gaussian blurs, it might be worth-while to test a
> current development snapshot build for Mac OS X [1]. The formula for the
> rendering of Gaussian blurs was recently improved for better performance
> and might show a noticeable difference while still using the same
> renderer as current stable versions. Note though that development builds
> are usually not recommended to be used in a productive environment [2].
>
> 2) memory leak with embedded images: refers to
> Bug #597689 “Memory leak when showing/hiding embedded images.”
> <https://bugs.launchpad.net/inkscape/+bug/597689>
> While this can contribute to increased memory usage, it doesn't cause a
> sudden spike as you originally described. As far as I remember from a few
> tests, it is not triggered by linked bitmap images (when importing you can
> choose between link or embed, and later on you can embed or extract images
> with 'Extensions > Images…').
>
...

[Beluga (buovjaga)]

Bug #608944 was marked a dupe of bug #706294, which I was unable to repro. Please re-test and report the current situation.

[Qantas94Heavy (qantas94heavy)]

Closing due to lack of response. If you have a similar issue, please check for bugs already reported here: https://gitlab.com/Qantas94Heavy