Are the performance improvements of 0.49 already in trunk?
We are using Inkscape to edit SVGs generated by the Maperitive OpenStreetMap renderer. Those files are very complex and Inscape is practially unuseable in the latest stable version.
We found on http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49 that there are performance improvements upcoming. So we installed the package from the PPA 1:0.48+devel+10922+30~natty1. Build 10922 is the latest build in the trunk branch as I see.
But using this version, there were no performance improvements notable.
Are those announce performance improvements already in trunk or do be have to use some other branch?
Best Regards, Alexander
On 25-01-12 14:34, Alexander (AddisMap) wrote:
We are using Inkscape to edit SVGs generated by the Maperitive OpenStreetMap renderer. Those files are very complex and Inscape is practially unuseable in the latest stable version.
We found on http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49 that there are performance improvements upcoming. So we installed the package from the PPA 1:0.48+devel+10922+30~natty1. Build 10922 is the latest build in the trunk branch as I see.
But using this version, there were no performance improvements notable.
Are those announce performance improvements already in trunk or do be have to use some other branch?
They are, and in many cases they are considerable. However, obviously your mileage may vary. Probably the best thing to do would be to post an example of a file that you're using and describing what actions in particular are very slow for you, then we can take a look to see what the problem might be.
Jasper van de Gronde <th.v.d.gronde@...125...> writes:
Are those announce performance improvements already in trunk or do be have to use some other branch?
They are, and in many cases they are considerable. However, obviously your mileage may vary. Probably the best thing to do would be to post an example of a file that you're using and describing what actions in particular are very slow for you, then we can take a look to see what the problem might be.
I was hoping those improvements are still to come.
Here is one sample file:
http://downloads.ethiopia-map.com/misc/city-center-map-with-mapdata.svgz
Basically everything is slow. Opening. Panning. Zooming. Moving all objects. But I admit it is a complex file. The computer that we are using is quite recent.
So whats to do?
Best Regards, Alexander
On 26-01-12 14:03, Alexander (AddisMap) wrote:
... Basically everything is slow. Opening. Panning. Zooming. Moving all objects. But I admit it is a complex file. The computer that we are using is quite recent.
So whats to do?
I gave it a quick try, and I wouldn't consider it particularly slow on the system I'm on now, using Inkscape 0.48(!). On my system, showing the entire drawing and zooming and panning around a bit never takes longer than about three seconds per full redraw (very roughly measured by counting in my head). Editing a path or dragging a small object is about as smooth as it gets.
Do you get similar results? If so, can you indicate why and how this causes problems for you? Perhaps there is a particular task you perform often that makes the current level of speed problematic? If you get fastly inferior performance, could you tell us a bit more about your system? (Specs, OS, etc.)
In terms of immediate relief, try tweaking the cache size on the "Rendering" page of the preferences for example (only possible in trunk).
On Thu, 26 Jan 2012 13:03:48 +0000 (UTC) Alexander (AddisMap) <alex@...2931...> wrote:
The computer that we are using is quite recent.
Seemed fine on my system,
Inkscape 0.48.2 r9819 Ubuntu 11.10 64 bit 6 Gb RAM, 3.4(?) GHz Quad Core AMD 64 bit
around 3 seconds for a page view redraw, as Jasper said. Seems you're not using any filters, no doubt it would slow down fast if you were.
Cheers -Terry
On 26/01/2012 14:03, Alexander (AddisMap) wrote:
Jasper van de Gronde<th.v.d.gronde@...125...> writes:
Are those announce performance improvements already in trunk or do be have to use some other branch?
They are, and in many cases they are considerable. However, obviously your mileage may vary. Probably the best thing to do would be to post an example of a file that you're using and describing what actions in particular are very slow for you, then we can take a look to see what the problem might be.
I was hoping those improvements are still to come.
Here is one sample file:
http://downloads.ethiopia-map.com/misc/city-center-map-with-mapdata.svgz
Basically everything is slow. Opening. Panning. Zooming. Moving all objects. But I admit it is a complex file. The computer that we are using is quite recent.
Tested on OS X Lion with 64bit builds, comparing 0.48.2 to r10922:
- Inkscape 0.48.2 (stable): Loading and rendering performance ok Selecting large (clone of) group with many stroked paths ok Editing (e.g. dragging a map symbol with the mouse) ok Node-editing e.g. a contour line ok
- Inkscape 0.48+devel r10922 (trunk) Loading and rendering performance ok Selecting large (clone of) group with many stroked paths slower Editing (e.g. dragging a map symbol with the mouse) very slow Node-editing e.g. a contour line slower
Probably, since the file has hundreds of stroked paths, working with it (beyond mere viewing) using a recent build from trunk is affected by the issue discussed in http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37456
In my tests, it's not really practicable with Inkscape 0.48+devel r10922 to do such a basic operation like dragging a newly drawn square around the canvas (with the mouse), nor e.g. any of the map symbols already existing in the current drawing.
Node-editing existing large stroked paths seems less affected (slowed down) by the new, preciser calculation of the visual bounding box, but there is still a noticeable slow-down compared to 0.48.2.
Hiding layers with complex paths does not help to increase the performance in current trunk (the slowdown still occurs).
Personally, I would recommend to stay with stable 0.48.2 for such files for now (and hide layers when working on details). AFAICT the greatest performance gains in current trunk are mainly for rendering of SVG filter effects, and overall memory usage (much lower). I do hope that the regression with (complex) stroked paths can be addressed before the release of 0.49.
~suv
participants (4)
-
Alexander (AddisMap)
-
Jasper van de Gronde
-
Terry Brown
-
~suv