March 2011 - Inkscape Devel - Inkscape Mailman

[Fwd: [Merge] lp:~ado-papas/inkscape/bug_167419 into lp:inkscape]
by ~suv 16 Mar '11

16 Mar '11

Anyone willing to help with testing/reviewing? IMHO this would fix an annoying issue with linked offsets. It would be great to have it merged into trunk before another pending merge (gsoc-cairo) possibly requires yet again a rewrite, as well as backporting the fix to the 0.48.x branch for 0.48.2 (if doable). ~suv -------- Original Message -------- Subject: [Merge] lp:~ado-papas/inkscape/bug_167419 into lp:inkscape Date: Thu, 10 Mar 2011 18:26:38 -0000 From: Adonis Papaderos <ado.papas@...1244...> Reply-To: mp+52899@...2499... To: mp+52899@...2499... Adonis Papaderos has proposed merging lp:~ado-papas/inkscape/bug_167419 into lp:inkscape. Requested reviews: Adonis Papaderos (ado-papas) ~suv (suv-lp) Related bugs: Bug #167419 in Inkscape: "square/circle/polygon/spiral and linked offset misbehaviours" https://bugs.launchpad.net/inkscape/+bug/167419 Bug #184341 in Inkscape: "Linked offsets ignore clone movement preferences" https://bugs.launchpad.net/inkscape/+bug/184341 Bug #239430 in Inkscape: "linked offset ungroup issue" https://bugs.launchpad.net/inkscape/+bug/239430 For more details, see: https://code.launchpad.net/~ado-papas/inkscape/bug_167419/+merge/52899 Fix some issues with linked offsets. Changed the rendering of the offset to take into account the transformation of the source object, as is the case with the use element, and copied the move compensation logic from uses to offsets. There is a speed penalty though because of this, since I cannot find a reliable method to predict whether there is a change to the source object data or a transformation applied to it. The second patch removes an optimization I implemented using the transform event, since this event is not emitted on undo and redo actions. -- https://code.launchpad.net/~ado-papas/inkscape/bug_167419/+merge/52899 You are requested to review the proposed merge of lp:~ado-papas/inkscape/bug_167419 into lp:inkscape.

1 0

Extensions - Slider in Int and Float widgets
by Nicolas Dufour 16 Mar '11

16 Mar '11

Hello, Revision 10103 adds horizontal sliders to the Int and Float extension widgets in order to make parameters a bit easier to handle. It perfectly fits large numbers (colors or angles related values) but may be less efficient with small range parameters (as in the SVG calendar extension). Thus I've implemented two modes (mimicking the radiobutton parameter), full (default, with slider) and minimal (no slider) that can be used by adding an appearance="<mode>" attribute to the int or float element in the inx file or internal extension structure. The size of the slider is the same for all widgets, 200px (about the same as the sliders used in Gimp). Please test and comment! Regards, -- Nicolas

3 5

plans on 0.49
by Alexandre Prokoudine 16 Mar '11

16 Mar '11

Hi, Do we have any plans re 0.49 and GSoC? Do we want releasing 0.49 before work on GSoC projects starts (in case we are accepted) which means end of May? If not, do we want releasing once a year which means 0.49 around August? Would it make sense figuring out now where we are currently and what we could for 0.49? Alexandre Prokoudine http://libregraphicsworld.org

8 21

Command line interface on Windows
by Jason La 16 Mar '11

16 Mar '11

Hi Inkscape community, Thanks for the app, it is proving to be very useful. For whatever reason, the .NET framework does not include any kind of SVG handling -- so Inkscape has been endlessly useful. I'm using it for a pretty simple purpose - converting SVG files to PNG or JPEG images. I'm just following the instructions from the FAQ to let the devs of our common usage of the CLI. Thanks again, Jason Jason La Associate Software Developer Tel: 805-898-8508 www.alg.com <http://www.alg.com/> Confidentiality Notice: This e-mail may contain confidential, proprietary information of ALG, A DealerTrack Company. It is intended solely for the named recipient(s) listed above and should be maintained in strictest confidence. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you have received this e-mail in error, please immediately notify the sender and delete this information from your computer and destroy any related paper copies.

1 0

possible save dialog bugs on Windows
by Michael Grosberg 15 Mar '11

15 Mar '11

I'm only seeing it on a single machine at work, but please take the time to see if you can reproduce it. perhaps it's just that one machine. I waited for 48.1 just to be sure it's not already solved but it seems like I still have this problem: When I create a new file and then attempt to save it, I have to explicitly add the "svg" extension. If I don't, the file is saved without an extension. Another issue I see on all both home and office machines: When I do a "Save As...", the save dialog opens with the file name field empty, when in most other applicatios it contains the current file name. Both issues are on Windows, I haven't tested on my Linux partition yet.

3 2

Re: [Inkscape-devel] Merging the Cairo branch
by john cliff 15 Mar '11

15 Mar '11

2011/3/15 Josh Andler <scislac@...400...>: > Hey, > > So, I really think that we should entertain the idea of merging the cairo > branch into trunk. The plan has been for us to not release 0.49 until it is > ready, so the couple outstanding bugs in cairo shouldn't be a huge > deterrent. We could also set up a PPA to produce the trunk builds of cairo & > pixman so that fixed libs are easily installable in the meantime (at least > for people using debian-based systems). I was talking to John Cliff and he > put forth a very good point which is that we really need to get as much > testing as possible on it prior to a release. > > Before it gets asked, yes Jon, color management is broken in it atm. The > likelihood of it getting fixed in a branch as opposed to trunk is next to > non-existent though... > > So, would people be okay with a little breakage of existing functionality to > get more testing of a cairofied Inkscape? bulia, I included you in the to > line here to help gauge the acceptability of this proposal. > > Cheers, > Josh > I think the more we can use this code the better, and having it tucked away in a branch isnt achieving that. Putting it in trunk forces us to fix what we find, and means we dont only start that process once cairo is uptodate enough in the distros. If we're gonna have to wait for the distros to be ready for us, we might as well be good and ready for them. Cheers John (sim)

1 0

Fwd: [Fwd: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor]
by Igor Novikov 15 Mar '11

15 Mar '11

On Tue, Mar 15, 2011 at 11:53 AM, Jasper van de Gronde < th.v.d.gronde@...528...> wrote: > 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. > May be Inkscape has accurate implementation but Inkscape document model is highly non effective. There is a simple comparing test. Just create 1000 rectangles, convert they into paths and measure memory usage in Inkscape, CorelDRAW and sK1. You will get approximately following numbers: Cold start/With document Inkscape 0.48 62Mb/140Mb CorelDRAW X3 47Mb/63Mb sK1 0.9.1 51Mb/62Mb So for the same drawing applications use: Inkscape 0.48 78Mb CorelDRAW X3 16Mb sK1 0.9.1 11Mb The test file you can fetch here: http://sk1project.org/files/test1000_rects.svg If you multiply objects (10k or more) you will see that Inkscape allocates 0.5Gb and more whereas Corel/sK1 uses less than 100Mb. Actually similar issues are observed in all mature applications because initial architecture was not designed with all the implemented features. Gimp, Scribus, Inkscape and our sK1 already faced with this problem. CorelDRAW has passed this milestone in ver.10 I think you remember that we have presented Cairo-based rendering in sK1 on LGM2007 and since that time we have a lot of experience in this issue (whereas "cairofication" for Inkscape is upcoming feature). Using this experience I would say that "cairofication" doesn't resolve all Inkscape rendering problems because Cairo (at least current stable version) is not fast. Concerning our project we have decided reimplementing sK1 and UniConvertor from scratch because the further development of just stuck in the architectural issues. We hope reporting results in our presentation on LGM2011, so I think we could discussing this in Montreal and it could be really useful for further Inkscape development. -- Regards, Igor Novikov sK1 Project http://sk1project.org

2 3

Fwd: Inkscape Wiki page DotDotDot has been changed by Airhogs777
by unknown＠example.com 15 Mar '11

15 Mar '11

The site referenced, http://www.dot-dot-dot.nl in the subject page, http://wiki.inkscape.org/wiki/index.php/DotDotDot looks like a parked domain from where I sit. The Wikipedia entry, http://en.wikipedia.org/wiki/Dot_Dot_Dot_(magazine) points to http://www.dot-dot-dot.us which looks more like something, but the site doesn't display well in Internet Explorer (Intentional?) and doesn't have much functionality in Firefox. Is Dot Dot Dot Magazine really useful to the Inkscape community? ---------- Forwarded message ---------- From: WikiAdmin - acspike@...34... Date: Mon, Mar 14, 2011 at 7:13 PM Subject: Inkscape Wiki page DotDotDot has been changed by Airhogs777 To: NeoPhyte Rep <InkscapeWiki.NeoPhyte_Rep@...2295...> Dear NeoPhyte Rep, The Inkscape Wiki page DotDotDot has been changed on 02:13, 15 March 2011 by Airhogs777, see http://wiki.inkscape.org/wiki/index.php/DotDotDot for the current version. See http://wiki.inkscape.org/wiki/index.php?title=DotDotDot&diff=0&oldid=1172 for all changes since your last visit. Editor's summary: - Contact the editor: mail: http://wiki.inkscape.org/wiki/index.php/Special:EmailUser/Airhogs777 wiki: http://wiki.inkscape.org/wiki/index.php/User:Airhogs777 There will be no other notifications in case of further changes unless you visit this page. You could also reset the notification flags for all your watched pages on your watchlist. Your friendly Inkscape Wiki notification system -- To change your watchlist settings, visit http://wiki.inkscape.org/wiki/index.php/Special:Watchlist/edit Feedback and further assistance: http://wiki.inkscape.org/wiki/index.php/Help:Contents

2 1

[Fwd: [Bug 733966] [NEW] Inkscape way to SLOW - Refactor]
by ~suv 15 Mar '11

15 Mar '11

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

11 14

Inkscape Website Progress...
by Ian Caldwell 15 Mar '11

15 Mar '11

Hello, here's an update on the website. We have made some nice progress and it is defiantly coming along. It's going to be launched in phases. Phase #1 will be the main site with all the content and Phase 2 will consist of various things for the user allowing them to be able to post their own tutorials and plugins etc. However in order to do that we need help! We need the following: 1. content writers to go through the site and improve on the existing write ups. 1. Additional old news needs to be ported over. We ported over all of 2010 and 2011 but we need all news ported over 2. Django developers to finish up the last few features After all that 3. we need translators to translate the various parts of the website You can follow the project here: https://code.launchpad.net/~inkscape-webadmin/inkscape-web/inkscape-web Also the site is visible at http://dev.inkscape.org please feel free to drop by on irc.freenode.net and join #inkscape-web Thanks, Ian Caldwell

12 25