[Fwd: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor]
Could some of the devs help with bug triage and comment on this recent report?
~suv
-------- Original Message -------- Subject: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor Date: Sat, 12 Mar 2011 18:49:58 -0000 From: Gary <733966@...1882...> Reply-To: Bug 733966 <733966@...1882...>
Public bug reported:
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.
** Affects: inkscape Importance: Undecided Status: New
Here's my "outsider's" (non-developer's) opinion: While I tend to agree, I think it's a pretty broad sweeping criticism, without many specific suggestions. However, good to see Gary's taking the bull by the horns and attempting to do something about it :-)
Gary, I'd highly recommend not switching to QT4 at the same time as trying to improve performance, even if QT is your favorite toolkit. AFAIU, Inkscape is pretty well invested in GTK, and trying to switch toolkits is such a huge job that it would completely eclipse any efforts to improve performance.
I know for a fact that GTK apps can be fast. I doubt if GTK is a factor in Inkscape's sluggish performance, per se.
Refactoring is a great idea, and using some profiling tools is another great idea. But don't forget that premature optimization is the root of all evil -- don't over-optimise, keep a keen eye for clean code over and above highly optimized code, and only optimize what actually needs it. http://c2.com/cgi/wiki?PrematureOptimization
I would LOVE to see Inkscape's performance addressed.
- Bryan
On Sun, Mar 13, 2011 at 08:31, ~suv <suv-sf@...58...> wrote:
Could some of the devs help with bug triage and comment on this recent report?
~suv
-------- Original Message -------- Subject: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor Date: Sat, 12 Mar 2011 18:49:58 -0000 From: Gary <733966@...1882...> Reply-To: Bug 733966 <733966@...1882...>
Public bug reported:
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.
** Affects: inkscape Importance: Undecided Status: New
-- You received this bug notification because you are a member of Inkscape Bug Team, which is subscribed to Inkscape. https://bugs.launchpad.net/bugs/733966
Title: Inkscape way to SLOW - Refactor
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I already did... it's not good for me to wake up and respond to stuff like this, but whatever.... when I saw the message I got frustrated and responded as nicely as I could.
On Sat, Mar 12, 2011 at 11:31 AM, ~suv <suv-sf@...58...> wrote:
Could some of the devs help with bug triage and comment on this recent report?
~suv
-------- Original Message -------- Subject: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor Date: Sat, 12 Mar 2011 18:49:58 -0000 From: Gary <733966@...1882...> Reply-To: Bug 733966 <733966@...1882...>
Public bug reported:
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.
** Affects: inkscape Importance: Undecided Status: New
-- You received this bug notification because you are a member of Inkscape Bug Team, which is subscribed to Inkscape. https://bugs.launchpad.net/bugs/733966
Title: Inkscape way to SLOW - Refactor
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mar 12, 2011, at 12:00 PM, Josh Andler wrote:
I already did... it's not good for me to wake up and respond to stuff like this, but whatever.... when I saw the message I got frustrated and responded as nicely as I could.
Added my $0.02
Is there any plan how we will speed-up performance in future. I mean: - fast (visual) response to the user - fast rendering
I know that we have: - tiling the image into pieces to decrease user response time - add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
Maybe we can put ideas somewhere in wiki?
my 2ct
Adib.
On Sat, Mar 12, 2011 at 9:31 PM, Jon Cruz <jon@...18...> wrote:
On Mar 12, 2011, at 12:00 PM, Josh Andler wrote:
I already did... it's not good for me to wake up and respond to stuff like this, but whatever.... when I saw the message I got frustrated and responded as nicely as I could.
Added my $0.02
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote:
Is there any plan how we will speed-up performance in future. I mean:
- fast (visual) response to the user
- fast rendering
I know that we have:
- tiling the image into pieces to decrease user response time
- add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.
Again, I'm not a coder, don't know about possible drawbacks of this suggestions, so... Just ignore me if being ignorant and/or stupid! :)
Vlada
Maybe we can put ideas somewhere in wiki?
my 2ct
Adib.
On Sat, Mar 12, 2011 at 9:31 PM, Jon Cruz <jon@...18...> wrote:
On Mar 12, 2011, at 12:00 PM, Josh Andler wrote:
I already did... it's not good for me to wake up and respond to stuff like this, but whatever.... when I saw the message I got frustrated and responded as nicely as I could.
Added my $0.02
In my opinion it would be best if cairo renders filters by itself. The computation of the pixel-buffers and transferring (eventually conversion to other pixel-formats) the pixel buffers from one library to an other consumes a lot of time.
Adib. --
On Sun, Mar 13, 2011 at 3:52 PM, Vladimir Savic <vladimir.firefly.savic@...400...> wrote:
On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote:
Is there any plan how we will speed-up performance in future. I mean:
- fast (visual) response to the user
- fast rendering
I know that we have:
- tiling the image into pieces to decrease user response time
- add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.
Again, I'm not a coder, don't know about possible drawbacks of this suggestions, so... Just ignore me if being ignorant and/or stupid! :)
Vlada
Maybe we can put ideas somewhere in wiki?
my 2ct
Adib.
On Sat, Mar 12, 2011 at 9:31 PM, Jon Cruz <jon@...18...> wrote:
On Mar 12, 2011, at 12:00 PM, Josh Andler wrote:
I already did... it's not good for me to wake up and respond to stuff like this, but whatever.... when I saw the message I got frustrated and responded as nicely as I could.
Added my $0.02
2011/3/13 Vladimir Savic <vladimir.firefly.savic@...400...>:
Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.
GEGL is not very well suited to interactive vector drawing. However, there is a standalone GEGL graph renderer and we could make an output plugin that saves such a graph.
2011/3/13 the Adib <theadib@...1439...>:
Is there any plan how we will speed-up performance in future. I mean:
- fast (visual) response to the user
- fast rendering
I know that we have:
- tiling the image into pieces to decrease user response time
- add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
The trunk only has OpenMP in Gaussian blur. The Cairo branch has it for all filters. But the main problem is with filters that depend on a lot of data, such as large radius Gaussian blur. Each tile is rendered separately, and large portions of the image have to be re-rendered over and over. If we can cache the intermediate data between tile renderings, it would give us a massive speedup.
An OpenCL backend for Cairo, or improvements in its OpenGL backend, would be the ultimate solution for modern systems. We could then use the GPU to compute the filters.
Regards, Krzysztof
On 3/13/11, Krzysztof Kosiński wrote:
GEGL is not very well suited to interactive vector drawing.
Ah, that explains why it has pluggable curve types and why the abandonded testing tool had path drawing with interactive node type selection on canvas :))) FYI, the plan is to use 2geom in GEGL in the future.
Alexandre Prokoudine http://libregraphicsworld.org
2011/3/13 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
Ah, that explains why it has pluggable curve types and why the abandonded testing tool had path drawing with interactive node type selection on canvas :))) FYI, the plan is to use 2geom in GEGL in the future.
I might have gotten the wrong impression. But I re-read the docs on the webpage, and it looks like you need to use Cairo to draw anything on the screen.
What about GPU acceleration? Cairo can (at least theoretically) do this.
Regards, Krzysztof
On 3/14/11, Krzysztof Kosiński wrote:
What about GPU acceleration? Cairo can (at least theoretically) do this.
http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu
Implemented (AFAIK): GPU-side buffers, few operations.
Alexandre Prokoudine http://libregraphicsworld.org
2011/3/13 Krzysztof Kosiński <tweenk.pl@...400...>
What about GPU acceleration? Cairo can (at least theoretically) do this.
http://doc.trolltech.com/4.7/qglwidget.html
Mature, well optimized implementation. The bug reporter does not mention Qt library in vain.
W dniu 14 marca 2011 07:49 użytkownik Igor Novikov <igor.e.novikov@...400...> napisał:
http://doc.trolltech.com/4.7/qglwidget.html
Mature, well optimized implementation. The bug reporter does not mention Qt library in vain.
There is a big difference between a widget that allows you to draw with OpenGL on it, and a 2D drawing API which is hardware-accelerated. GTK also has such a widget (GtkGLExt).
2011/3/13 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu
Implemented (AFAIK): GPU-side buffers, few operations.
Does it actually work and give a performance boost? It looks unmaintained.
Regards, Krzysztof
On 2011-03-13 15:52, Vladimir Savic wrote:
On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote:
Is there any plan how we will speed-up performance in future. I mean:
- fast (visual) response to the user
- fast rendering
I know that we have:
- tiling the image into pieces to decrease user response time
- add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.
Could we please slow down just a bit. Basically someone has come and claimed, with some justification, that Inkscape is slow. It is, at least in some respects (no one files bugs for cases in which Inkscape performs marvelously). But we are working on performance issues continuously and I think pretty much any Inkscape developer knows at least a few things he would like to speed up.
As for getting some results, apart from some UI issues, which are important but which are not exactly my specialty, filters are probably the main cause of perceived slowness. I would like to make a couple of remarks about that. Inkscape mostly has implementations that are quite accurate, which often results in slightly worse performance than you might otherwise see. Personally I feel that this is good, as this way you at least get the right output, and with a bit more effort even high quality results can often be obtained with very good performance (but yes, it does require more effort, and therefore more patience).
To summarize and extend what some others said, the following could have a big impact: - Smarter handling of tiles - Use of GPU - Faster algorithms - "Simplification" of filters - Tricks to make things "look" faster
Tiles can be quite devastating to performance when doing Gaussian blur (as Krzysztof mentioned), as even with the IIR code we may still have to deal with huge margins. I think that for the specific case of Gaussian blur it might be possible to work out something to prevent this (and I would be willing to work on at least the theoretical part), but the main issue is that it would probably require a fundamental change in how we deal with tiles.
Using the GPU can make things a lot faster, simply because the GPU is generally a lot faster for filter-like operations. Keep in mind though that this is no silver bullet, and especially if you need to transfer image data between main memory and the graphics card a lot. In general this item is very much orthogonal to other improvements.
It might come as a surprise to some, but at least the morphological filters can be sped up relatively easily simply by using a different algorithm. Currently the speed of these filters depends on the size of the structuring element, and this is suboptimal. There are algorithms that aren't even that complicated that allow you to compute the exact same filter without the performance depending on the size of the structuring element (if anyone is interested in coding this up I can provide references/explanation).
Currently, when rendering a filter, we just iterate over the filter primitives without looking at what we're doing. In some cases it might be possible to collapse two filter primitives to one, process a smaller area (because we know that later on only a small part is used), reorder and collapse primitives, detect special cases and process them more efficiently, etc. This can also tie in with using the GPU or LLVM, as you could imagine generating a single program per filter. This approach will not speed up a simple blurring operation or something like that, but it can help in dealing with some of the more complex filters.
And as someone else mentioned, sometimes something just needs to look fast. Apart from carefully choosing when to rerender we could also try some tricks like only updating part of an image while the slider is held (unless you have plenty of time of course), smarter caching (for example, if you change the color of a blurred object with just a flat color it's quite easy to update the blurred version without reblurring), etc.
As for GEGL, following last year's LGM I had a closer look at it, because I too wondered whether we couldn't somehow share code. Well. I still think it could be interesting, but I was unable to get it to work at all under Windows (after much experimentation I managed to get it to compile, but then it just crashed on me) and got zero response when asking about it on their mailing list. Don't get me wrong, I think the project is great, and I even think it might be interesting to use it for normal rendering (not just filters), to remove any artificial barrier between filters and the rest of the rendering code, but as it is now it at least needs some intense Windows love.
just a small question here ..I've compiled last year I think ..in September or October the gsoc-gpu - branch of Inkscape. ..it was a work in progress but it was so fast for some filters
the question is - can we see some things added gradually to normal releases ? - or this work has to be included as a whole ?.
2011/3/15 Jasper van de Gronde <th.v.d.gronde@...528...>:
On 2011-03-13 15:52, Vladimir Savic wrote:
On Sun, 2011-03-13 at 15:37 +0100, the Adib wrote:
Is there any plan how we will speed-up performance in future. I mean:
- fast (visual) response to the user
- fast rendering
I know that we have:
- tiling the image into pieces to decrease user response time
- add OpenMP to filter functions
On the roadmap is conversion to cairo. But cairo does not render filters at all. I read that LLVM could speedup when generating the filter code .....
Maybe I misunderstood the concept behind filter rendering, but what about joining efforts with GEGL guys and using that library? I guess it will develop faster, both big apps that would use it (Inkscape and GIMP) will benefit from joined development, bugs will be fixed faster, etc. If I understand correctly, GIMP will use GEGL for pixel computations too and pass the resoult to cairo for drawing on canvas.
Could we please slow down just a bit. Basically someone has come and claimed, with some justification, that Inkscape is slow. It is, at least in some respects (no one files bugs for cases in which Inkscape performs marvelously). But we are working on performance issues continuously and I think pretty much any Inkscape developer knows at least a few things he would like to speed up.
As for getting some results, apart from some UI issues, which are important but which are not exactly my specialty, filters are probably the main cause of perceived slowness. I would like to make a couple of remarks about that. Inkscape mostly has implementations that are quite accurate, which often results in slightly worse performance than you might otherwise see. Personally I feel that this is good, as this way you at least get the right output, and with a bit more effort even high quality results can often be obtained with very good performance (but yes, it does require more effort, and therefore more patience).
To summarize and extend what some others said, the following could have a big impact: - Smarter handling of tiles - Use of GPU - Faster algorithms - "Simplification" of filters - Tricks to make things "look" faster
Tiles can be quite devastating to performance when doing Gaussian blur (as Krzysztof mentioned), as even with the IIR code we may still have to deal with huge margins. I think that for the specific case of Gaussian blur it might be possible to work out something to prevent this (and I would be willing to work on at least the theoretical part), but the main issue is that it would probably require a fundamental change in how we deal with tiles.
Using the GPU can make things a lot faster, simply because the GPU is generally a lot faster for filter-like operations. Keep in mind though that this is no silver bullet, and especially if you need to transfer image data between main memory and the graphics card a lot. In general this item is very much orthogonal to other improvements.
It might come as a surprise to some, but at least the morphological filters can be sped up relatively easily simply by using a different algorithm. Currently the speed of these filters depends on the size of the structuring element, and this is suboptimal. There are algorithms that aren't even that complicated that allow you to compute the exact same filter without the performance depending on the size of the structuring element (if anyone is interested in coding this up I can provide references/explanation).
Currently, when rendering a filter, we just iterate over the filter primitives without looking at what we're doing. In some cases it might be possible to collapse two filter primitives to one, process a smaller area (because we know that later on only a small part is used), reorder and collapse primitives, detect special cases and process them more efficiently, etc. This can also tie in with using the GPU or LLVM, as you could imagine generating a single program per filter. This approach will not speed up a simple blurring operation or something like that, but it can help in dealing with some of the more complex filters.
And as someone else mentioned, sometimes something just needs to look fast. Apart from carefully choosing when to rerender we could also try some tricks like only updating part of an image while the slider is held (unless you have plenty of time of course), smarter caching (for example, if you change the color of a blurred object with just a flat color it's quite easy to update the blurred version without reblurring), etc.
As for GEGL, following last year's LGM I had a closer look at it, because I too wondered whether we couldn't somehow share code. Well. I still think it could be interesting, but I was unable to get it to work at all under Windows (after much experimentation I managed to get it to compile, but then it just crashed on me) and got zero response when asking about it on their mailing list. Don't get me wrong, I think the project is great, and I even think it might be interesting to use it for normal rendering (not just filters), to remove any artificial barrier between filters and the rest of the rendering code, but as it is now it at least needs some intense Windows love.
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (11)
-
Alexandre Prokoudine -
Bryan Hoyt | Brush Technology -
Igor Novikov -
Jasper van de Gronde -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
SorinN -
the Adib -
Vladimir Savic -
~suv