Inkscape

Bug #733966
Comment #12

Comment 12 for bug 733966

Revision history for this message

Gary (gary-herbst) wrote on 2011-03-12: Re: [Bug 733966] Re: Inkscape way to SLOW - Refactor

#12

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 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
>

Gary-

On Sat, Mar 12, 2011 at 4:57 PM, Jon A. Cruz <jon@joncruz.org> 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 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
>