December 2013 - Inkscape Devel

Inkscape performance - two suggestions
by Paul Kallnbach 19 Dec '13

19 Dec '13

Dear list, this is my first contact to the inkscape developer community and I hope my messages is not received as being overly critical or even offending as I'm clearly talking about things I do not fully understand. You're all doing a great job on Inkscape and I l-o-v-e the upcoming 0.49 release! It is no secret that Inkscape suffers some performance issues when editing or just viewing complex svg files, especially at high zoom levels. Particularly there is a noticable lag between a user action (e.g. zooming in) and the start of the rendering process. I'm not an experienced c++ programmer nor do I know much about how Inkscape works internally but I crawled through the code, following the chain of actions Inkscape does, when its processing its user actions and it turned out that commenting out the following lines instantly removes the bespoken delay and thus greatly accelerates the responsiveness of the program for complex drawings: in drawing-item.cpp, line 586 - 589: :572 if (_cached) { if (_cache) { _cache->prepare(); #ifdef WITH_CSSBLEND set_cairo_blend_operator( ct, _blend_mode ); #endif _cache->paintFromCache(ct, carea); if (!carea) return RENDER_OK; } else { // There is no cache. This could be because caching of this item // was just turned on after the last update phase, or because // we were previously outside of the canvas. Geom::OptIntRect cl = _drawing.cacheLimit(); cl.intersectWith(_drawbox); /* if (cl) { _cache = new DrawingCache(*cl); } */ } } else { // if our caching was turned off after the last update, it was already // deleted in setCached() :593 } I don't know much about Inkscapes caching mechanisms but clearly a cache that slows down a program instead of accelerating it is broken. Furthermore this else-statement should be a rather rare exception to be called but the program behaviour indicates its called not only for every object but also every time the canvas is updated, which might indicate a more complicated issue.. I am fully aware that just commenting this out is not a solution to the problem but maybe somebody more experienced could have a look at the functions involved and come up with a more sophisticated solution? The second suggestion I wanted to make is more a design decision I'm afraid. It is about Inkscape interrupting the redraw process (see sp-canvas.cpp, around line 1967) At the moment the redraw is aborted if its not done in less than 1 microsecond, which, at least on my system, almost never happens unless I pan very slowly. The result are very ugly artefacts on the edge of the screen when the user pans/scrolls the canvas (see this screenshot for clarification: http://www.gorilla-computing.de/misc/inkscape_screenshot.jpg). Has ever been considered to increase that limit so Inkscape can actually finish the redraw more often? I experimented around a bit and a value of 100ms seems to do the job just fine - especially with the cache lag gone. And it should still be low enough to process different user input when needed. If it is not possible to hardcode that limit to a sensible value, maybe one could make it a slider in the options->render menu? Thanks for your considerations! Best, Paul

1 0

new scaling/stretching behaviour with Preserved Transforms
by alvinpenner 18 Dec '13

18 Dec '13

This is an attempt to summarize the types of scaling behaviour that can occur, and to highlight a few remaining unresolved issues. Only the behaviour of the visual bbox will be discussed. In Inkscape 0.48.4 there were two types of stretching behaviour, depending on the choice of the preference for Scale Stroke Width. The choice of the preference for Optimized/Preserved Transforms did not affect the visual appearance in Inkscape, although it did in other renderers. With the implementation of the new Cairo renderer both of these preferences now affect the visual appearance, as they should. So there are now 4 possible results. The attached file 4boxes.svg has four identical boxes in a horizontal row. After stretching vertically with the Select tool (F1) we get file 4boxes_12851.svg. The four types of stretch used here were, from left to right: scale/optimized, no scale/optimized, scale/preserved, no scale/preserved. The first three cases scale more or less as expected, the fourth case is a bit unexpected. Since the idea of a constant (apparent) stroke width is meaningless in the case of a preserved transform, what has happened here is that the geometric mean of the apparent horizontal stroke and the apparent vertical stroke has been kept constant during the stretch, which is why the stroke along the horizontal axis is so narrow. Upon looking closer, case 3, scaled/preserved, has a few minor inconsistencies: it is too narrow and there is a vertical offset. These have been addressed in rev 12852. The result is shown in the file 4boxes_12852.svg. There are two remaining issues which may be more difficult to solve. In case 4, no scale/preserved, there is a remaining vertical offset. The offset is actually more serious than it appears to be, because it is persistent, it does not go away even after performing a round trip by contracting the shape again. It appears to be related to the fact that the stretching was asymmetric. If you drag at a 45 degree angle, then there is no offset. This will be reported elsewhere as a bug. The second unresolved issue is that the appearance during the drag is not the same as the appearance after releasing the object (Bug 1258271). Hoping to raise the visibility of this behaviour because this has provoked some discussion in the past, Bug 805392, Bug 805793; and since I have no idea how to fix the remaining issues. 4boxes.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes.svg> 4boxes_12851.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes_12851.svg> 4boxes_12852.svg <http://inkscape.13.x6.nabble.com/file/n4969050/4boxes_12852.svg> Cheers, Alvin -- View this message in context: http://inkscape.13.x6.nabble.com/new-scaling-stretching-behaviour-with-Pres… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2 2

possible bug?
by TimeWaster 18 Dec '13

18 Dec '13

i have the attached document: <svg [...] width="602.36218" height="336.04724" [...] viewBox="0 0 170 94.840002"> <sodipodi:namedview [...] inkscape:document-units="mm" [...] > in inkscape "custom size" is set to px, "default units" is set to mm. width and heigth are the size of the document in pixel, all other numbers are in mm. (they all have no unit specified, but i know it because of the dimensions of the drawing) shouldn't the width and height parameter be width="602.36218px" instead of width="602.36218" since the document wide unit is mm (even the viewBox is in mm)? i am using r12832 right now. i think this is related to https://bugs.launchpad.net/inkscape/+bug/605089 but it says it is fixed there, which i cannot confirm. and even if you say that width should always be in px, having no explicit unit given makes it harder (more obfuscated) for people to understand and parse the documents. regards, TimeWaster -- Save a printer manufacturer. Print this e-mail unless it's really necessary not to do so.

2 1

Re: [Inkscape-devel] Dealing with OS reported bugs
by Bryce Harrington 17 Dec '13

17 Dec '13

On Tue, Dec 17, 2013 at 08:30:28AM +0000, Nicolas Dufour wrote: > On Sun, Dec 15, 2013 at 07:42:49PM +0100, Kris De Gussem wrote: > >> I was wondering how to deal with bug reports automatically submitted by the > >> operating system. It is often hard to verify for these bugs how exactly one > >> could to provoke the issue but on the other hand it may be clear from the > >> backtrace that some null pointer check (or related thing) is missing). > > It's particularly difficult to deal with the Ubuntu automatic reports, > mainly because they often don't include steps to reproduce. We can try > to fix it thanks to the backtrace, but we have no certainty that it is > actually fixed without the steps. So what should we do? Close as soon > as we have committed a fix or wait until someone finds a way to > reproduce and confirm the fix works. I don't think there can be a hard and fast rule here; it's kind of a judgment call. For X.org bugs in Ubuntu, where there was a crash we didn't know how to repro but the stacktrace pointed out the flaw (a null pointer deref or whatever), I'd commit the patch and mark the bug fixed. We would only need the steps to repro and confirmation of the fix if we needed to backport the fix to a stable release. When the stacktrace didn't point out the flaw definitively, then we would indeed need to get steps to repro. If we had an idea for a patch, I'd post it to the bug report (and put a test package with the patch into a PPA), and wait on committing it to mainline until a user confirmed it. We usually only did this for crashes and lockups that were being hit by a lot of users, so even if one person was unresponsive, we could wait until another person filed a new bug, or commented on the original one. In a lot of cases the crash or hang wasn't deterministic but tended to occur periodically over N hours, so if they ran the package and used it for > 2*N hours we called it good. It's worth noting that the automatic collecting tool avoids creating new bug reports if it finds one with the same stack trace that still has an open distro task. So, being a little aggressive at closing these bugs when you suspect they're fixed is okay - the system will file a new one if it's still crashing for someone. My guess for Inkscape is that the former case is going to be more applicable. Perhaps suv has better advice on Inkscape policy here? Of course, if the codebase is frozen for a release, there'll be stricter rules, since we do want to make sure a committed fix really does fix the issue, but there'll be policy guidance given when we're at that point. By the way, the automatically generated bug reports can be controlled on the ubuntu side. We can arrange to collect some additional logs from the system at the time of the crash. (Very useful for X.org bug reports; maybe less so for Inkscape.) Also, there is a site at errors.ubuntu.com where ALL reported crashes appear, even if the user doesn't file a bug report. This site counts how many of each crash were reported for each Ubuntu release, and links to the bug report if there is one. You have to register to gain access to the detailed data (let me know if you're applying and I'll put in a good word with the ubuntu folks.) So right now, for package 0.48.4-1ubuntu3, the top crashers hit by users this past month are: Bug 1047748 (71 crashes) sp_dtw_color_profile_event Bug 1216167 (14 crashes) pathv_to_linear_and_cubic_beziers (8 crashes) sp_guideline_destroy (8 crashes) sp_ctrlpoint_set_color The interface also allows creating bug reports for crashes that don't yet have one. I created 1261918 as an example. Looks like there's a bunch of crashes that don't have bug reports yet. The detail crash report page shows a full stack trace, and a table showing other instances of the crash, what package version and ubuntu version were in use, and the date and time the crash occurred. You can also look at other examples of the stack trace, which can sometimes be handy to compare data or examine race conditions. For X.org I found this tool very helpful for prioritizing what crashers to work on, and identifying where backports of a fix to earlier stable releases would bring good bang for the buck. HTH, Bryce

1 0

Powerstroke questions
by Tom Lechner 17 Dec '13

17 Dec '13

Hi, I really love the powerstroke path effect, but some questions. 1. How accessible is the stroke information? From the file, it appears it is stored as a series of points, and stroke properties are derived from proximity to the original path. Perhaps there is an option to output more explicit information so that anything building on top of powerstroke can use it? If there is no possibility of outputing a kind of cache of powerstroke info, are there easy to use functions in the actual code to get this kind of information? I have been working on a mesh along path interface (not quite directly in inkscape yet), which could be adapted to apply gradients perpendicular to paths, make paths change color in the path direction, or perhaps be a base for inserting series of etching lines that conforms to a base path. Having access to powerstroke width profiles would be a great asset for these kinds of extensions. 2. Does the powerstroke computer apply the width always centered on the path? If the top and bottom were allowed to operate independently, it would be a single interface for both line offsetting (with only one powerstroke point) and for powerstroking itself. Thinking ahead to animation, tweaks like this could be useful there. -Tom ------ tomlechner.com

2 1

Re: [Inkscape-devel] lib2geom development, make test fail?
by Andreas Lobinger 17 Dec '13

17 Dec '13

Hello colleagues, 1) it's correct, the wiki points to a subversion repository https://lib2geom.svn.sourceforge.net/svnroot/lib2geom/lib2geom/trunk which i checked out as version r2059, the svn log | head tells me: lobi1@...3065...:~/lib2geom/trunk$ svn log | head ------------------------------------------------------------------------ r2059 | tweenk | 2010-07-21 22:18:35 +0200 (Mi, 21 Jul 2010) | 2 lines (and last check-in more than 3 years ago doesn't look like recent development...). This version runs cmake with everything found except: -- blas Includes, Compile and Link Flags: NOT FOUND -- pycairo Includes, Compile and Link Flags: NOT FOUND generates a makefile, make breaks with: lobi1@...3065...:~/lib2geom/trunk$ make [ 1%] Building CXX object src/2geom/CMakeFiles/2geom.dir/affine.cpp.o In file included from /home/lobi1/lib2geom/trunk/src/2geom/affine.cpp:15:0: /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:40: error: ‘size_t’ was not declared in this scope /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:40: note: suggested alternatives: /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:155:26: note: ‘std::size_t’ /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:155:26: note: ‘std::size_t’ /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:46: error: template argument 1 is invalid /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:46: error: template argument 2 is invalid /home/lobi1/lib2geom/trunk/src/2geom/utils.h:44:53: error: ‘size_t’ has not been declared make[2]: *** [src/2geom/CMakeFiles/2geom.dir/affine.cpp.o] Error 1 make[1]: *** [src/2geom/CMakeFiles/2geom.dir/all] Error 2 make: *** [all] Error 2 which looks strangely as C++ header trouble. 2) I followed the link in http://inkscape.org/en/develop/getting-started/#bazaar and in section Inkscape development tells me:The geometry library lib2geom, written in C++, is intended to eventually become a separate project. You can get the latest version of lib2geom from its Launchpad repository<https://launchpad.net/lib2geom> . So i bzr from the launchpad repository, bzr log | head tells me: lobi1@...3065...:~/lib2geom/lib2geom$ bzr log | head ------------------------------------------------------------ revno: 2161 committer: Johan B. C. Engelen <j.b.c.engelen@...3066...> branch nick: lib2geom timestamp: Mon 2013-12-09 22:00:17 +0100 message: use proper std:: namespace for std::size_t, because of cstddef include. fixes build for some ppl ------------------------------------------------------------ which i considered a lot more recent. The cmake claims the same missing as above, make however runs through and produces both the library and the toy programs. make test fails as: ... 60% tests passed, 6 tests failed out of 15 Total Test time (real) = 1.00 sec The following tests FAILED: 2 - bezier-test (Failed) 3 - chain-test (Failed) 4 - path-test (Failed) 6 - sbasis-test (Failed) 8 - convex-test (Failed) 11 - cg-test (Failed) Errors while running CTest make: *** [test] Error 8 3) My system is a std 12.04 Ubuntu on lobi1@...3065...:~/lib2geom/lib2geom$ uname -a Linux mark 3.2.0-56-generic-pae #86-Ubuntu SMP Wed Oct 23 17:51:27 UTC 2013 i686 i686 i386 GNU/Linux ? Wishing a happy day, Andreas

3 2

Fwd: possible bug?
by TimeWaster 17 Dec '13

17 Dec '13

*push* if noone answers till tomorrow i will open a bug report for it. regards, TimeWaster -------- Original Message -------- Subject: [Inkscape-devel] possible bug? Date: 15.12.2013 16:15 From: TimeWaster <sebi@...2963...> To: Inkscape Devel Mailingliste <inkscape-devel(a)lists.sourceforge.net> Reply-To: i have the attached document: <svg [...] width="602.36218" height="336.04724" [...] viewBox="0 0 170 94.840002"> <sodipodi:namedview [...] inkscape:document-units="mm" [...] > in inkscape "custom size" is set to px, "default units" is set to mm. width and heigth are the size of the document in pixel, all other numbers are in mm. (they all have no unit specified, but i know it because of the dimensions of the drawing) shouldn't the width and height parameter be width="602.36218px" instead of width="602.36218" since the document wide unit is mm (even the viewBox is in mm)? i am using r12832 right now. i think this is related to https://bugs.launchpad.net/inkscape/+bug/605089 but it says it is fixed there, which i cannot confirm. and even if you say that width should always be in px, having no explicit unit given makes it harder (more obfuscated) for people to understand and parse the documents. regards, TimeWaster ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

1 0

lib2geom development, make test fail?
by Andreas Lobinger 17 Dec '13

17 Dec '13

Hello, i wanted to use lib2geom in an own project and have difficulties to compile and run correctly; so my co from bzr_lp can cmake, make, but make test fails (for 6 tests, starting with bezier). This is also visible in the toys. Can someone point me please, how to connect to the development and how and where to ask questions. It also would be nice, to clarify the dependencies (BLAS is not found, but it's not clear, what this means). Wishing a happy day, Andreas

2 1

Fwd: Re: [scribus-dev] C++11
by Johan Engelen 16 Dec '13

16 Dec '13

Hi all, I asked the Scribus guys what their plans are regarding C++11. They had not thought about it much, but I got a very interesting reply, that is relevant for us too. Please read below. regards, Johan -------- Original Message -------- From: - Thu Nov 07 23:35:19 2013 Date: Thu, 07 Nov 2013 02:21:04 +0100 From: Jean Ghali <jghali@...373...> To: Scribus Development Mailing List <scribus-dev@...3050...>, jbc.engelen@...2592... Subject: Re: [scribus-dev] C++11 Hi, For making the switch to C++11, all C++ dependencies have to be compiled using C++11 too. It is indeed dangerous to link C++11 objects and C++ objects compiled according to previous standards: - http://gcc.gnu.org/wiki/Cxx11AbiCompatibility - http://stackoverflow.com/questions/9408656/do-we-need-to-recompile-librarie… - http://stackoverflow.com/questions/10065055/why-is-stdlist-bigger-on-c11 So basically the main requirements for us to switch to C++11 would be that qt binaries provided by distros are compiled according to C++11. I don't known if this is the case currently but i doubt it. Cheers, Jean Ghali Le 06/11/2013 20:05, Johan Engelen a écrit : > Hi all, > I'm rooting for requiring C++11 for lib2geom ASAP. How badly would this hurt Scribus > development? ;) > Are there any plans about when to make the switch to C++11 for Scribus? > > (I'm not subscribed to the list, so please also send replies directly to my address) > > Cheers, > Johan > (Inkscape and 2geom developer)

2 3

Recognizing a circle from a 1 + 3N Bezier description?
by mathog 16 Dec '13

16 Dec '13

SVG has a radial gradient type but neither EMF nor EMF+ do. Instead EMF+ has a gradient type that can be generalized to a radial: set color1 at an interior point and color2 on a closed path around it, and the intermediate points' colors are determined by the position along the ray from the center to the bounding curve. When PowerPoint saves a radial gradient via "save picture as" to an EMF file it also creates an EMF+ description. In the cases tested those paths looks like this: 1213769.875000,856342.937500 < 1213769.875000,1358353.125000 806810.187500,1765312.875000 304800.000000,1765312.875000 < -197210.218750,1765312.875000 -604169.937500,1358353.125000 -604169.937500,856342.937500 < -604169.937500,354332.718750 -197210.218750,-52627.000000 304800.000000,-52627.000000 < 806810.187500,-52627.000000 1213769.875000,354332.718750 1213769.875000,856342.937500 < The first point has type "start" and all the others have type "Bezier. The "<" indicates the points that are actually on the circle, and the points are grouped to emphasize how they work. These correspond to this drawing, with the point at 9:00 repeated once: http://www.mathworks.com/matlabcentral/fx_files/6844/2/CircleApproxbyCubicB… If the goal is to import this gradient from the EMF+ this bezier must be recognized as a circle. That might also be worthwhile for other circles encoded as a similar path. Now if the circles were only ever encoded with 13 points in this manner it would be pretty easy to spot one and convert it to a circle. But there might be 25 points in another circle representation, or something else. Does anyone know of a relatively straightforward test to apply to a curve like this (1 + 3N Bezier points) to see if it is a circle (within an error limit)? For the gradients we also have the location of the center point, but that won't be true for general curves. Thanks, David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

3 4