Speed issues with inkscape on ubuntu 8.10 64bit

I forgot to mention im running 64bit version of ubuntu.

I have Kubuntu on an 64bit AMDx2, no striped raids or such and am moderately happy with the performance, could be snappier but not so bad except when I've lots of blurs and things.

Post the SVG files somewhere and I'd be happy to try them and see what I can spot.

Hi, and thanks for the quick response!

I have uploaded the SVG files in question to my server:

http://o3s.com/Slow_as_HELL.svg

http://o3s.com/Fast.svg

I hope you will figure out something. In the meantime I will be trying out inkscape for windows running in a virtual machine.

Thanks!

--- On Mon, 4/6/09, pbhj <email address hidden> wrote:

> From: pbhj <email address hidden>
> Subject: Re: [Question #66551]: Speed issues with inkscape on ubuntu 8.10 64bit
> To: <email address hidden>
> Date: Monday, April 6, 2009, 1:36 AM
> Your question #66551 on Inkscape changed:
> https://answers.launchpad.net/inkscape/+question/66551
>
> Status: Open => Answered
>
> pbhj proposed the following answer:
> I have Kubuntu on an 64bit AMDx2, no striped raids or such
> and am
> moderately happy with the performance, could be snappier
> but not so bad
> except when I've lots of blurs and things.
>
> Post the SVG files somewhere and I'd be happy to try
> them and see what I
> can spot.
>
> --
> If this answers your question, please go to the following
> page to let us
> know that it is solved:
> https://answers.launchpad.net/inkscape/+question/66551/+confirm?answer_id=1
>
> If you still need help, you can reply to this email or go
> to the
> following page to enter your feedback:
> https://answers.launchpad.net/inkscape/+question/66551
>
> You received this question notification because you are a
> direct
> subscriber of the question.

[I'm just a user incidentally, just in case you thoguht otherwise]

The slow one has 137 objects, the quick one has 24.
The slow one had 9 un-vacuumed defs, the other 1.
The slow one includes several large paths of up to 12000 nodes.

A 12000 node bezier path isn't simple IMO - I'd expect this file to be slow to redraw, perhaps I expect too little?

If you feel this is an application problem then you should file a bug report.

Before I file a bugreport, I would like to share two new observations:

1. The "smaller" SVG sometimes also began acting slow.

2. The paths in the "larger" SVG that are in the middle of the document frame are the same as in the "smaller" SVG file. They do not overlap with any of the other parts, and yet they are still slow. Especially when zooming in so that the middle path covers the entire window.

In any graphics application, space partitioning is a crusial optimization, and I can only assume without looking at the inkscape code that you have a very efficient space partitioning algorithm in place. Hopefully.

Thanks for the input!

father:
I'm using a development version compiled a couple of minutes ago.
I can confirm that it redraws slow, but I found some things that maybe you should keep an eye on:

- When you have so many complex elements in the same document (the traced circuit board designs), use layers.
Don't have them all together. You can always turn off a layer's visibility temporarily to edit the rest faster.
- Switch to outline or no filters mode and check again. In my case, nofilter and outline were lightning fast, even with all the objects in the same layer.
- Always tweak the results of the traced bitmaps. Sometimes there are just too many nodes (you can use CTRL+L to simplify, and adjust the simplify threshold from the preferences).

My conclusion is that, even while is true that your file redraws painly slow in its original form, you can optimize your workflow to avoid that.
My other conclusion is that the major slowdown is caused by something with the filters. Take the objects with filters to another layer and turn it off when you want to edit the complex paths.
Definitely there are some optimization work to do to avoid that annoying negative influence of the filtered objects over the speed of non-filtered ones (even when the filtered are offscreen.
That last part maybe deserves a bug report.

Oh, I found it!!!
I'm afraid it's your fault, buddy :-)

Switch to outline mode (CTRL+KEYPAD5)
Look the group of the three boards on the left side.
There is a huge transparent rectangle with a hell of a blur filter applied on it.
Its bounding box covers the three boards on the left and a part of the board that is on the page, making the redrawing of all of them painfully slow.
Remove that rectangle and check again ;-)

I'm filing a bug report anyway. 100% Transparent objects should be avoided, at least filters should be de-activated to avoid this kind of accidents.