Inkscape way too SLOW - Refactor

[Gary]

Guys truly it is time to stop adding features to Inkscape and go back and refactor the code to fix bus and the terrible performance issues. There is little excuse for it to be at ver .48 and performance to be slow sluggish. Even the about box repaints the logo/image very slowly. That alone would have told me I have performance issues. At what point do you stop trying to add features and go back and address performance? My recommendation is to get a better handle and control over the development effort and split your team and branch to allow some to work on new features and others the refactoring of the code and eventual merge. When I launched it for the first time a while back I nearly laughed at the performance. Then expecting someone to address it in .48 would have been an expectation.

Do everyone a favor and place in your roadmap a REAL item to address performance and refactoring the code. This sluggish performance is across ALL platforms. For any developer on the team to be tolerant of such or even think of asking what hardware is foolish. Any junior level developer can easily determine the performance issues are within the code.

As of now I am going to kick off my own branch of this code and move it to QT4 for the UI and begin refactoring for performance. I will make that split in the branch available for those who want a highly performance version of InkScape.

I would invite you to address performance.

[Alexandre Prokoudine (alexandre-prokoudine)]

> At what point do you stop trying to add features and go back and address performance?

I think there's a little misconception about present, future and past tenses you have there ;)

Performance has already been addressed during GSoC2010 with two projects, one of them being port of rendering to Cairo. Have a go at http://inkscape.org/archive.php?lang=en&year=2010&month=09, last news item, please.

> My recommendation is to get a better handle and control over the development effort and split your team

Splitting what's left of the team isn't likely to be a better control over development.

> When I launched it for the first time a while back I nearly laughed at the performance.

We all need a chuckle sometimes

> Do everyone a favor and place in your roadmap a REAL item to address performance and refactoring the code.

0.49 is already supposed to be refactoring-focused release. The roadmap page probably doesn't say that, but it never was a real roadmap anyway.

> As of now I am going to kick off my own branch of this code and move it to QT4 for the UI

Well, good luck with silver bullets.

> I would invite you to address performance.

And I invite you to inkscape-devel@ to tell us what exactly you could do to improve performance.

P.S. No, Qt4 port won't help.

[ScislaC (scislac)]

Gary,

You should really think about joining the irc channel or developer mailing list. If you did, you would know that the entire point of the current (0.49) dev cycle is to refactor, it indeed is not about features. If you were to join either place to discuss, you'd also know that we have a branch that has replaced the renderer with cairo. The cairo branch is significantly faster than trunk, and in one example file with trunk it uses 755megs of ram, and in the cairo branch it uses only 115megs of ram by comparison. Unfortunately we still can't merge that branch because there is no version of cairo released that has specific bugs we need fixed (they are fixed in cairo & pixman trunk though).

Please also know that reporting things like this are counterproductive and you're not terribly likely to get people to want to do things for you by insulting them. I'd invite you to join us in continuing to improve Inkscape proper instead of wasting time switching toolkits and libraries, but from your attitude, I'm not sure that you work well with others.

[Diederik van Lierop (mail-diedenrezi)]

Yes Inkscape can be slow, but most likely this is due to using bitmap filters. Speeding up Inkscape is therefore not as much a matter of refactoring, it's a new feature that's needed: 2D graphics hardware acceleration, across all OSes. And that's not a trivial thing to implement :-(

[Jon A. Cruz (jon-joncruz)]

Unfortunately switching to Qt is not a magic bullet that will give any real performance benefit. In fact, it will most likely do the opposite as the existing code is heavily dependent on Glib/GTK. Gluing on a Qt layer will require either several layers of wrapping or a complete replacement of the Inkscape codebase with some entirely new code.

And, yes, I do speak from experience. Among other things I have shipped commercial Qt-based applications.

[Gary (gary-herbst)]

Well then post a date for the release of such. Again for the current state
of the app to be at .48.1 and still exhibit poor performance is ludicrous. I
have well over 23 yrs of software development across platforms and industry
as well as managing such projects ad the sr. level. It would be nice to see
this clearly stated in the roadmap and an implementation date for the
"optimized" code.

On Sat, Mar 12, 2011 at 1:53 PM, Alexandre Prokoudine <
<email address hidden>> wrote:

> > At what point do you stop trying to add features and go back and
> address performance?
>
> I think there's a little misconception about present, future and past
> tenses you have there ;)
>
> Performance has already been addressed during GSoC2010 with two
> projects, one of them being port of rendering to Cairo. Have a go at
> http://inkscape.org/archive.php?lang=en&year=2010&month=09, last news
> item, please.
>
> > My recommendation is to get a better handle and control over the
> development effort and split your team
>
> Splitting what's left of the team isn't likely to be a better control
> over development.
>
> > When I launched it for the first time a while back I nearly laughed at
> the performance.
>
> We all need a chuckle sometimes
>
> > Do everyone a favor and place in your roadmap a REAL item to address
> performance and refactoring the code.
>
> 0.49 is already supposed to be refactoring-focused release. The roadmap
> page probably doesn't say that, but it never was a real roadmap anyway.
>
> > As of now I am going to kick off my own branch of this code and move
> it to QT4 for the UI
>
> Well, good luck with silver bullets.
>
> > I would invite you to address performance.
>
> And I invite you to inkscape-devel@ to tell us what exactly you could do
> to improve performance.
>
> P.S. No, Qt4 port won't help.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/733966
>
> Title:
> Inkscape way to SLOW - Refactor
>
> Status in Inkscape: A Vector Drawing Tool:
> Opinion
>
> Bug description:
> Guys truly it is time to stop adding features to Inkscape and go back
> and refactor the code to fix bus and the terrible performance issues.
> There is little excuse for it to be at ver .48 and performance to be
> slow sluggish. Even the about box repaints the logo/image very slowly.
> That alone would have told me I have performance issues. At what point
> do you stop trying to add features and go back and address
> performance? My recommendation is to get a better handle and control
> over the development effort and split your team and branch to allow
> some to work on new features and others the refactoring of the code
> and eventual merge. When I launched it for the first time a while back
> I nearly laughed at the performance. Then expecting someone to address
> it in .48 would have been an expectation.
>
> Do everyone a favor and place in your roadmap a REAL item to address
> performance and refactoring the code. This sluggish performance is
> across ALL platforms. For any developer on the team to be tolerant of
> such or even think of asking what hardware is ...

[Gary (gary-herbst)]

Thanks for all the responses. Truly enlightening and it does appear the
roadmap does not clearly state all of this. Yes QT4 is not a magic bullet. I
have full understanding of such and ample experience in developing software
and managing the development of such to understand the port to QT4 will not
address the issues.

So how about I join the dev team and lend a hand? I'm more than willing to.

Gary-

On Sat, Mar 12, 2011 at 1:53 PM, Alexandre Prokoudine <
<email address hidden>> wrote:

> > At what point do you stop trying to add features and go back and
> address performance?
>
> I think there's a little misconception about present, future and past
> tenses you have there ;)
>
> Performance has already been addressed during GSoC2010 with two
> projects, one of them being port of rendering to Cairo. Have a go at
> http://inkscape.org/archive.php?lang=en&year=2010&month=09, last news
> item, please.
>
> > My recommendation is to get a better handle and control over the
> development effort and split your team
>
> Splitting what's left of the team isn't likely to be a better control
> over development.
>
> > When I launched it for the first time a while back I nearly laughed at
> the performance.
>
> We all need a chuckle sometimes
>
> > Do everyone a favor and place in your roadmap a REAL item to address
> performance and refactoring the code.
>
> 0.49 is already supposed to be refactoring-focused release. The roadmap
> page probably doesn't say that, but it never was a real roadmap anyway.
>
> > As of now I am going to kick off my own branch of this code and move
> it to QT4 for the UI
>
> Well, good luck with silver bullets.
>
> > I would invite you to address performance.
>
> And I invite you to inkscape-devel@ to tell us what exactly you could do
> to improve performance.
>
> P.S. No, Qt4 port won't help.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/733966
>
> Title:
> Inkscape way to SLOW - Refactor
>
> Status in Inkscape: A Vector Drawing Tool:
> Opinion
>
> Bug description:
> Guys truly it is time to stop adding features to Inkscape and go back
> and refactor the code to fix bus and the terrible performance issues.
> There is little excuse for it to be at ver .48 and performance to be
> slow sluggish. Even the about box repaints the logo/image very slowly.
> That alone would have told me I have performance issues. At what point
> do you stop trying to add features and go back and address
> performance? My recommendation is to get a better handle and control
> over the development effort and split your team and branch to allow
> some to work on new features and others the refactoring of the code
> and eventual merge. When I launched it for the first time a while back
> I nearly laughed at the performance. Then expecting someone to address
> it in .48 would have been an expectation.
>
> Do everyone a favor and place in your roadmap a REAL item to address
> performance and refactoring the code. This sluggish performance is
> across ALL platforms. For any developer on the team to be tolerant of
> such or even think of asking what h...

[ScislaC (scislac)]

Gary,

If we had any expected release date we would post it. Unfortunately as mentioned, a good chunk of the refactoring work which has already done can't be merged in trunk until there is a version of cairo released with bugfixes that we need. We don't know when that will be, so we can't even begin to guess.

As for joining the dev team, the first step is to join the developer mailing list. https://lists.sourceforge.net/lists/listinfo/inkscape-devel

We require that you submit two patches before you are given commit access. All you need to do is search the bug tracker and find a 2 bugs you'd like to fix, and submit a patch for each one. After they are accepted and committed, we will give you commit access to the bzr repo. The top rule for our trunk though is that it must always be useable and in an unbroken state. Everyone on the dev team uses it for production work, so just keep this in mind.

As for refactoring work, once you've been granted commit access, please drop a line on the devel mailing list and we can go over what we are looking to do for 0.49.

[Alexandre Prokoudine (alexandre-prokoudine)]

@ScislaC

AFAIK, latest dev version of Cairo and Pixman does have the fixes, but they won't land to major Linux distributions until autumn 2011.

@Gary

To set release dates we need a 10x as many active team members. Projects like GNOME and KDE can do that, we can't. Especially, as mentioned before, we depend on 3rd party libraries.

There is a whole bunch of things to do for refactoring. For instance, we use some local copies of libraries that are out of date and missing features of their newer upstream versions. If you are willing to help, you'll never be short of tasks to accomplish. That I can promise to you :)

[Gary (gary-herbst)]

Sounds good. I will do as you have indicated so I can take the steps needed
to assist.

Thanks again,
Gary-

On Sat, Mar 12, 2011 at 3:22 PM, ScislaC <email address hidden> wrote:

> Gary,
>
> If we had any expected release date we would post it. Unfortunately as
> mentioned, a good chunk of the refactoring work which has already done
> can't be merged in trunk until there is a version of cairo released with
> bugfixes that we need. We don't know when that will be, so we can't even
> begin to guess.
>
> As for joining the dev team, the first step is to join the developer
> mailing list. https://lists.sourceforge.net/lists/listinfo/inkscape-
> devel
>
> We require that you submit two patches before you are given commit
> access. All you need to do is search the bug tracker and find a 2 bugs
> you'd like to fix, and submit a patch for each one. After they are
> accepted and committed, we will give you commit access to the bzr repo.
> The top rule for our trunk though is that it must always be useable and
> in an unbroken state. Everyone on the dev team uses it for production
> work, so just keep this in mind.
>
> As for refactoring work, once you've been granted commit access, please
> drop a line on the devel mailing list and we can go over what we are
> looking to do for 0.49.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/733966
>
> Title:
> Inkscape way to SLOW - Refactor
>
> Status in Inkscape: A Vector Drawing Tool:
> Opinion
>
> Bug description:
> Guys truly it is time to stop adding features to Inkscape and go back
> and refactor the code to fix bus and the terrible performance issues.
> There is little excuse for it to be at ver .48 and performance to be
> slow sluggish. Even the about box repaints the logo/image very slowly.
> That alone would have told me I have performance issues. At what point
> do you stop trying to add features and go back and address
> performance? My recommendation is to get a better handle and control
> over the development effort and split your team and branch to allow
> some to work on new features and others the refactoring of the code
> and eventual merge. When I launched it for the first time a while back
> I nearly laughed at the performance. Then expecting someone to address
> it in .48 would have been an expectation.
>
> Do everyone a favor and place in your roadmap a REAL item to address
> performance and refactoring the code. This sluggish performance is
> across ALL platforms. For any developer on the team to be tolerant of
> such or even think of asking what hardware is foolish. Any junior
> level developer can easily determine the performance issues are within
> the code.
>
> As of now I am going to kick off my own branch of this code and move
> it to QT4 for the UI and begin refactoring for performance. I will
> make that split in the branch available for those who want a highly
> performance version of InkScape.
>
> I would invite you to address performance.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/inkscape/+bug/733966/+subscribe
>

[ScislaC (scislac)]

@Alexandre,

Fixes exist in trunk, but not in a current stable release. I've asked Kees to see if he can get Carl to backport the fixes to a stable release so Natty can get them (and obviously win32 & macports would have them much sooner too). Kees sent the email, so all we can do is be hopeful that Carl will go for it.

[Jon A. Cruz (jon-joncruz)]

Actually, the first and far most important step is to identify exactly what is "slow".

Usually we are talking about "unresponsive UI" issues. There are many ways to address these, but we need to know where to look. We also need to know in detail, not just "the app is slow".

For example, some users reported that changing colors via the sliders in the Fill & Stroke dialog was slow. I was able to measure some things and got it working much "faster" by actually slowing down that portion. What I did was clean up the UI integration to no longer generate hundreds of repaints per second (far faster than a normal user could even see). Instead events were pruned down and some updates deferred. Objectively the result was actually slower updating in response to user input on the color sliders. Subjectively, however, the operation of the program in that area suddenly felt much faster.

Switching to a Cairo renderer may allow some pixel-pushing speedups. However we will gain a lot more by addressing specific user interface responsiveness issues. Instead of trying to redraw thousands of vectors hundreds of times a second, we can instead switch to dragging proxy bitmaps and gain significant responsiveness speedups (even when combined with Cairo rendering). There are many other such UI tunings we can do... but we need to know which areas and aspects of the UI to focus on.

[Gary (gary-herbst)]

Ok here's a very good example. Bring up the About box in .48 or prior and
look at the repaint. An about box with image should pop. Last time I saw
such a slow repaint was back in Windows 1.0. I have had a look at just
something as simplistic as this under Windows7, OSX, Linux. All exhibit the
same issue. And by slow yes I refer to the UI screen painting. The overall
UI is extremely slow. However, think we have been through this interation so
I will be attempting to assist and join the dev team.

My words are not meant as a critic but a generalized statement. I myself am
always focused on the performance of code, the code I develop, and the code
my team and off-shore developers develop. As such this always sits are the
forefront of my mind.

Gary-

On Sat, Mar 12, 2011 at 4:57 PM, Jon A. Cruz <email address hidden> wrote:

> Actually, the first and far most important step is to identify exactly
> what is "slow".
>
> Usually we are talking about "unresponsive UI" issues. There are many
> ways to address these, but we need to know where to look. We also need
> to know in detail, not just "the app is slow".
>
> For example, some users reported that changing colors via the sliders in
> the Fill & Stroke dialog was slow. I was able to measure some things and
> got it working much "faster" by actually slowing down that portion. What
> I did was clean up the UI integration to no longer generate hundreds of
> repaints per second (far faster than a normal user could even see).
> Instead events were pruned down and some updates deferred. Objectively
> the result was actually slower updating in response to user input on the
> color sliders. Subjectively, however, the operation of the program in
> that area suddenly felt much faster.
>
> Switching to a Cairo renderer may allow some pixel-pushing speedups.
> However we will gain a lot more by addressing specific user interface
> responsiveness issues. Instead of trying to redraw thousands of vectors
> hundreds of times a second, we can instead switch to dragging proxy
> bitmaps and gain significant responsiveness speedups (even when combined
> with Cairo rendering). There are many other such UI tunings we can do...
> but we need to know which areas and aspects of the UI to focus on.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/733966
>
> Title:
> Inkscape way to SLOW - Refactor
>
> Status in Inkscape: A Vector Drawing Tool:
> Opinion
>
> Bug description:
> Guys truly it is time to stop adding features to Inkscape and go back
> and refactor the code to fix bus and the terrible performance issues.
> There is little excuse for it to be at ver .48 and performance to be
> slow sluggish. Even the about box repaints the logo/image very slowly.
> That alone would have told me I have performance issues. At what point
> do you stop trying to add features and go back and address
> performance? My recommendation is to get a better handle and control
> over the development effort and split your team and branch to allow
> some to work on new features and others the refactoring of the code
> and eventual merge. When I launched it fo...

[John Cliff (johncliff)]

Thats because we render the about box from SVG, not a rendered image. Its one of the ways we eat dogfood.
We also encourage the about images to have examples of some of the latest features, which generally results in fairly taxing files to render. The debate on prerendered vs SVG has been had a couple of times, perhaps the trunk should have svg and the release static renders, I dont know.
incidentally if the first time speed issue was down to startup, thats the fonts being cached.

[Gary (gary-herbst)]

I figured you did since it was so obvious this was SVG or a vector rendered
image being rendered through the same slow 2D code. Prerendered images are
the only way to go and not sure why it was even an option to use SVG. A bit
unheard of for most apps to use anything but prerendered in the About since
the about is of little value and is a pop-up and as such must render
quickly. Dates back to the first incarnations of "About" boxes well over
12yrs ago

On Mon, Mar 14, 2011 at 4:38 PM, John Cliff <<email address hidden>
> wrote:

> Thats because we render the about box from SVG, not a rendered image. Its
> one of the ways we eat dogfood.
> We also encourage the about images to have examples of some of the latest
> features, which generally results in fairly taxing files to render. The
> debate on prerendered vs SVG has been had a couple of times, perhaps the
> trunk should have svg and the release static renders, I dont know.
> incidentally if the first time speed issue was down to startup, thats the
> fonts being cached.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/733966
>
> Title:
> Inkscape way to SLOW - Refactor
>
> Status in Inkscape: A Vector Drawing Tool:
> Opinion
>
> Bug description:
> Guys truly it is time to stop adding features to Inkscape and go back
> and refactor the code to fix bus and the terrible performance issues.
> There is little excuse for it to be at ver .48 and performance to be
> slow sluggish. Even the about box repaints the logo/image very slowly.
> That alone would have told me I have performance issues. At what point
> do you stop trying to add features and go back and address
> performance? My recommendation is to get a better handle and control
> over the development effort and split your team and branch to allow
> some to work on new features and others the refactoring of the code
> and eventual merge. When I launched it for the first time a while back
> I nearly laughed at the performance. Then expecting someone to address
> it in .48 would have been an expectation.
>
> Do everyone a favor and place in your roadmap a REAL item to address
> performance and refactoring the code. This sluggish performance is
> across ALL platforms. For any developer on the team to be tolerant of
> such or even think of asking what hardware is foolish. Any junior
> level developer can easily determine the performance issues are within
> the code.
>
> As of now I am going to kick off my own branch of this code and move
> it to QT4 for the UI and begin refactoring for performance. I will
> make that split in the branch available for those who want a highly
> performance version of InkScape.
>
> I would invite you to address performance.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/inkscape/+bug/733966/+subscribe
>

[ScislaC (scislac)]

Gary,

While prerendered might be the norm for other applications it hasn't been for Inkscape. The primary reason why we ship with the SVG About is so that people can crack it open and see how it was made. Perhaps it should be brought up on the developer mailing list about possibly ALSO distributing with a prerendered PNG file to use in-application for a faster load of that dialog. I will also mention though that in the cairo branch it is significantly faster to come up and render (still not "immediate" though, but much better).

[Krzysztof Kosinski (tweenk)]

Interactive editing performance is now significantly improved. Gaussian blur performance still needs improvements though.

[Baditaflorin (baditaflorin)]

And the possibility for a notice that you can load the svg image directly from the about box :) For instance i don`t know from where to load the picture. I could search but it would be more simple for people to be able to load directly from there

[Turbo (axelhc)]

Hi all.

My two cents:

How about Inkscape doing multithreading and x64 so it can use all the RAM available ??

Regards.

Turbo.

[Liam P. White (liampwhite)]

@Turbo

> How about Inkscape doing multithreading

Inkscape already did multi-threading and has been doing so for a long time, simply because it is GTK application. Taking advantage of threading implementations such as OpenMP or even GLib's own threading mechanism does not increase the amount of memory available to the application, nor in this case is it memory bottlenecks that are making Inkscape slower.

> and x64 so it can use all the RAM available ??

If you are on a amd64 GNU/Linux distribution, have compiled Inkscape with the system compiler on OS X 10.7 or greater, or have used 64-bit Windoze/MSYS to compile Inkscape, there is a high likelihood that your binary is already running in 64-bit mode. 64-bit is also not a magic bullet to make the program faster -- using 64-bit programs can make register transfers faster as they can be done in increments of 8 bytes instead of 4 bytes, but this is not where Inkscape is slow.

Rather, Inkscape is slow because it unnecessarily pipes out signals during long-running events (such as dragging nodes or gradient handles, or selecting thousands of objects on the canvas), and does not have a well structured framework for coordinating the events that it emits. I am working on more of this in the experimental branch -- selecting lots of nodes is several times faster, working with hundreds of gradients is faster, the renderer is slightly faster, and so on. This is again reiteration of what Jon Cruz mentioned earlier, about slowing down emission to speed up Inkscape.