Dear Inkscape developers,
first of all I wish to thank you for your great work, Inkscape is extremely useful!
One thing I noticed is that using blur and sometimes opacity makes Inkscape behave slow. It's not only when moving / scaling objects that have blur or opacity values applied but also the whole document editing seems to be slower then. It would be great if these features could be optimized in one of the next versions. Please let me know if I should file a bug report on this request.
Best Gero Mudersbach
Gero Mudersbach wrote:
Dear Inkscape developers,
first of all I wish to thank you for your great work, Inkscape is extremely useful!
One thing I noticed is that using blur and sometimes opacity makes Inkscape behave slow. It's not only when moving / scaling objects that have blur or opacity values applied but also the whole document editing seems to be slower then. It would be great if these features could be optimized in one of the next versions. Please let me know if I should file a bug report on this request.
Blur is to some degree inherently slow, and Inkscape's implementation is already pretty fast, but obviously it's always possible to make things even faster. For example, one thing for which Inkscape has some preliminary support is multi-threading. On a machine with multiple cores Inkscape can take advantage of this to divide the work of blurring over multiple cores.
If you feel that blur is too slow for your work, be sure to file a feature request. And preferably include some (simple) example of a situation that is too slow for you.
As for opacity, this is more surprising. Theoretically it shouldn't be much slower than no opacity (in both cases the different layers are blended using more or less the same code). If you can provide any example file(s)+action(s) that show a clear difference in speed of the interface, please file a bug report as soon as possible.
On 04/27/2009 12:53 PM, Jasper van de Gronde wrote:
Blur is to some degree inherently slow, and Inkscape's implementation is already pretty fast, but obviously it's always possible to make things even faster. For example, one thing for which Inkscape has some preliminary support is multi-threading. On a machine with multiple cores Inkscape can take advantage of this to divide the work of blurring over multiple cores.
If you feel that blur is too slow for your work, be sure to file a feature request. And preferably include some (simple) example of a situation that is too slow for you.
In my experience blur is *painfully* slow and always was (now I am running a SVN snapshot) tot he degree that for complex files you may have to use the Outline mode and to export to PNG with GIMP. I spread the various part of an image to various layers and toggle layer visibility on and off, to have as little as possible blur visible at a time, to carry my work.
As for opacity, this is more surprising. Theoretically it shouldn't be much slower than no opacity (in both cases the different layers are blended using more or less the same code). If you can provide any example file(s)+action(s) that show a clear difference in speed of the interface, please file a bug report as soon as possible.
I don't have complains about opacity, probably he is using opacity in combination with blur.
Nicu Buculei wrote:
On 04/27/2009 12:53 PM, Jasper van de Gronde wrote:
... If you feel that blur is too slow for your work, be sure to file a feature request. And preferably include some (simple) example of a situation that is too slow for you.
In my experience blur is *painfully* slow and always was (now I am running a SVN snapshot) tot he degree that for complex files you may have to use the Outline mode and to export to PNG with GIMP. I spread the various part of an image to various layers and toggle layer visibility on and off, to have as little as possible blur visible at a time, to carry my work.
I just drew a rectangle and a circle, applied two different blurs and did some zooming. Only when zooming in considerably did Inkscape become somewhat slow for my tastes. So obviously at least one of the following is the case: - I use a faster machine (Core 2 Duo at 1.33Ghz) - My standards for judging Inkscape's speed are different - I use Inkscape for considerably less complex drawings (obviously the example above was overly simple, but I have also done some more complex things with blur without having much of a problem with Inkscape's speed)
In the end you'll probably always have situations in which you would have to switch to outline mode or switch off filters. But in my opinion there is still a lot of room for improvement in some specific situations, where it is possible to use a fundamentally faster approach.
So if you can identify specific situations in which blur is clearly too slow this may help to guide future optimizations.
BTW, if you want to try multi-threading, set the following in the options group in preferences.xml (if you have more than 2 cores you may want to experiment with setting numthreads higher): <group numthreads="2" id="threading" />
If I remember, photoshop is rasterizing all effects and the result in stored in memory( for each object? layer ?) and directly re-applied when panning or changing upper layers without complex calculation.
When the zoom value is changed, the rasterization is remade, etc. Do you think that something like that could be applied to inkscape ?
One more thing that could be usefull is a "Cancel rendering" key (like escape) because sometimes, on complex graphics, you have to wait 30s-45s that the rendering is completed to change something (color, go to outline mode, etc.) on slower computer.
2009/4/27 Jasper van de Gronde <th.v.d.gronde@...528...>
Nicu Buculei wrote:
On 04/27/2009 12:53 PM, Jasper van de Gronde wrote:
... If you feel that blur is too slow for your work, be sure to file a feature request. And preferably include some (simple) example of a situation that is too slow for you.
In my experience blur is *painfully* slow and always was (now I am running a SVN snapshot) tot he degree that for complex files you may have to use the Outline mode and to export to PNG with GIMP. I spread the various part of an image to various layers and toggle layer visibility on and off, to have as little as possible blur visible at a time, to carry my work.
I just drew a rectangle and a circle, applied two different blurs and did some zooming. Only when zooming in considerably did Inkscape become somewhat slow for my tastes. So obviously at least one of the following is the case:
- I use a faster machine (Core 2 Duo at 1.33Ghz)
- My standards for judging Inkscape's speed are different
- I use Inkscape for considerably less complex drawings (obviously the
example above was overly simple, but I have also done some more complex things with blur without having much of a problem with Inkscape's speed)
In the end you'll probably always have situations in which you would have to switch to outline mode or switch off filters. But in my opinion there is still a lot of room for improvement in some specific situations, where it is possible to use a fundamentally faster approach.
So if you can identify specific situations in which blur is clearly too slow this may help to guide future optimizations.
BTW, if you want to try multi-threading, set the following in the options group in preferences.xml (if you have more than 2 cores you may want to experiment with setting numthreads higher): <group numthreads="2" id="threading" />
Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (4)
-
Gero Mudersbach -
Jasper van de Gronde -
Nicu Buculei -
Yann Papouin