performance problems and possible remedies?
by Yale Zhang
Hi. I'm using Inkscape to author a comic and the slow speed for certain
things is very annoying. I'm already have OpenMP turned on and using 4
cores.
1. *large blurs are slow* - I'm an expert with writing SIMD code, so I was
thinking about vectorizing the Gaussian IIR filter with SIMD intrinsics,
even though it's harder than for a FIR. But I noticed there isn't any SIMD
code in Inkscape so does that mean it's something to avoid.
I'm pretty sure no current compiler is smart enough to vectorize it, and
besides, Inkscape is compiled with -O2, meaning -ftree-vectorize isn't on
by default.
2. *when there's a large image (raster based) background - scrolling in a
zoomed region is very slow*
I compiled the latest 0.49 code with GCC profiling and it shows this:
33.98 22.47 22.47 exp2l
21.29 36.55 14.08 log2l
17.57 48.17 11.62 pow
7.12 52.88 4.71 658 0.01 0.01
ink_cairo_surface_srgb_to_linear(_cairo_surface*)
6.72 57.32 4.44 563 0.01 0.01
ink_cairo_surface_linear_to_srgb(_cairo_surface*)
5.51 60.96 3.64 1216 0.00 0.00
Inkscape::Filters::FilterGaussian::~FilterGaussian()
5.23 64.42 3.46 internal_modf
0.59 64.81 0.39 _mcount_private
0.41 65.08 0.27 __fentry__
0.12 65.16 0.08 GC_mark_from
0.09 65.22 0.06 5579 0.00 0.00
Geom::parse_svg_path(char const*, Geom::SVGPathSink&)
0.06 65.26 0.04 35320 0.00 0.00
bounds_exact_transformed(std::vector<Geom::Path,
std::allocator<Geom::Path> > const&, Geom::Affine const&)
0.06 65.30 0.04 8 0.01 0.01
convert_pixbuf_normal_to_argb32(_GdkPixbuf*)
0.05 65.33 0.03 885444 0.00 0.00
std::vector<Geom::Linear, std::allocator<Geom::Linear>
>::_M_fill_insert(__gnu_cxx::__normal_iterator<Geom::Linear*,
std::vector<Geom::Linear, std::allocator<Geom::Linear> > >, unsigned long
long, Geom::Linear const&)
The cost is absolutely dominated by ink_cairo_surface_srgb_to_linear() and
ink_cairo_surface_linear_to_srgb(). My first instinct was to optimize
those 2 functions, but then I thought why are those even being called every
time I scroll through the image?
Why not convert the images up front to linear and stay that way in memory?
If that can't be done, then my optimization approach is:
1. replace ink_cairo_surface_srgb_to_linear() with a simple 3rd degree
polynomial approximation (0.902590573087882 - 0.010238759806148x +
0.002825455367280x^2 + 0.000004414767235x^3) and vectorize with SSE
intrinsics. The approximation was calculated by minimizing the square error
(maxError = 0.313) over the range [10, 255]. For x < 10, it uses simple
scaling.
2. replace ink_surface_linear_to_srgb() with a vectorized implementation
of pow(). Unlike srgb_to_linear(), a low degree polynomial can't be used
due to the curve having larger high order derivatives. An alternative would
be piece wise, low order polynomials.
The main question I have is what degree of accuracy is desired? Certainly,
it doesn't need double precision pow() since the input is only 8 bits! Is
+- 0.5 from the true value (before quantization) OK or do people depend on
getting pixel perfect results?
UJ
6 years, 12 months
Create releases more regularly
by Sebastian Zartner
Hi there,
I initially asked at
inkscapeforum.com<http://www.inkscapeforum.com/viewtopic.php?f=22&t=15755&p=63224>and
was told to better post my request to this mailing list.
I wonder if it wouldn't be possible to create releases more regularly.
Currently there are many months or even years between each release of
Inkscape.
Bug fixes should get out more quickly and it should be possible to try out
new features of upcoming versions. Most users don't have the possibility to
build Inkscape by their own, so they have to wait for the next release.
Unfortunately the provided development downloads are not synchronized,
hosted on different third-party web sites and out of date (currently
especially the Windows version).
So I suggest to create a (more or less) fixed fast release cycle for normal
releases (e.g. every two or three months) and periodically (e.g. every one
or two weeks) create alpha versions.
Alpha versions should be built (maybe even automatically) for all supported
OSes and hosted directly on inkscape.org.
Sebastian
7 years, 7 months
Re: [Inkscape-devel] Devlibs 46 too slow
by Mark Titchener
I tried your modified build with an NVidia Quadro 1000M on Windows 7 and it
seemed okay to me.
> Le Jeudi 21 novembre 2013 9h09, Nicolas Dufour <nicoduf@...48...> a ?crit
> :
> > I'm still investigating the issue, and just found out that the computers
> I
> > used to reproduced the bug were all using an Intel GPU. Tests with an
> nvidia
> > GeForce 210 (GT218) show no slowness at all.
>
> Could some Windows users help me? I'd like to confirm the slowness only
> affects Intel graphics cards. Could you test a modified Inkscape binary
> (from ftp://download.tuxfamily.org/inkscape/inkscape-12282-cairo-1.12.8.7z),
> give your graphic card model and tell me if it's slow or not? IMHO it could
> be a blocker for 0.49 on Windows.
>
>
7 years, 7 months
non-Unicode symbol fonts do not work on Windows. Bug 165665. Do we need the flag USE_PANGO_WIN32 ?
by Alvin Penner
ref : https://bugs.launchpad.net/inkscape/+bug/165665
I believe this bug can be fixed by disabling the flag USE_PANGO_WIN32 in
line 19 of src/libnrtype/FontFactory.h. When I do this on Windows XP, I gain
about 35 new fonts. Not all of these new fonts are useable, but the most
interesting ones, such as CommercialPi, Symbol, Technic, Webdings,
Wingdings, MonoType Sorts, TechnicLite are working well, both in Inkscape
and in IE9.
This is a Windows-specific bug which hides symbol fonts, and does not
occur in Gimp 2.6 on Win XP. As far as I can tell, the Gimp source code does
not contain any analogue or equivalent of the flag USE_PANGO_WIN32.
Would there be any objection if I disable this flag, or does it serve a
specific purpose that is essential?
tia
- Alvin Penner
--
View this message in context: http://old.nabble.com/non-Unicode-symbol-fonts-do-not-work-on-Windows.-Bu...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
8 years, 4 months
Transformation center issues
by Diederik van Lierop
Hi people,
The past weeks I've been trying to fix some transformation center offset
regressions, which were caused by the new unit/viewbox stuff. That should
all work reasonably well again, but it remains a headache. IMHO this
transformation center handling is broken by design, and judging by some
comments in the code I'm not the only one to think so. It requires all
kinds of special casing everywhere transformations are being applied, due
to the transformation center being expressed in horizontal/vertical
coordinates, relative to the center of the bounding box. Does anybody know
why it was designed like this?
If there are no strong objections, then I'd propose to use absolute
coordinates, and to apply transformations as if it were simply a point of a
path. This would make code much cleaner. We will no longer need to call
document->ensureUpToDate() to force an update of the bounding box everytime
the center is requested or changed. It might also allow us to get rid of
the weird behavior of the transformation center (which should rotate with
the item in case an object is rotated!)
Not that I'm going to change this now, but I might get to this after the
0.91 release.
Diederik
8 years, 7 months
C++11 for Experimental Branch?
by Tavmjong Bah
Hi,
I noticed a bunch of 'for' loops in Liam's code and that got me
wondering about using C++11 in the experimental branch as 'auto' is so
much nicer that "std::map<SPDocument*,int>::iterator iter". When can we
start using C++11?
I noticed that http://wiki.inkscape.org/wiki/index.php/C%2B%2B11 only
shows results for one Window's compiler. Is there a test program we can
run? Fedora 20 is using GCC 4.8 and clang 3.4; both support 'auto' (GCC
since 4.4).
Tav
8 years, 10 months
0.91 Bug Hunt Status
by Bryce Harrington
Development focus: 0.91.x series
Pts Bug Age Date Assignee Description
=== === === ==== ======== ===========
6 1299948 0 05/11 Liam P. White LPEs with linked paths sometimes do not recalculate after undo
6 1310266 0 05/10 jazzynico Update the man page with '-i -j' for plain SVG export options
6 1315416 0 05/03 jazzynico [0.91 Tutorial Review] issues with "Basic" tutorial
6 1315453 0 05/05 Ryan Lerch [0.91 Tutorial Review] issues with "Shapes" tutorial
6 1315457 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with "Advanced" tutorial
6 1315480 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with " Bitmap tracing" tutorial
6 1315483 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with " Calligraphy" tutorial
6 1315485 0 05/05 Ryan Lerch [0.91 Tutorial Review] issues with "Elements of Design" tutorial
6 1315487 0 05/06 Ryan Lerch [0.91 Tutorial Review] issues with "tips and tricks" tutorial
6 1316591 0 05/06 Mohamed IKBEL Boulabiar copy-paste typo in the dbus document interface
6 1318289 0 05/11 Masato HASHIMOTO preferences > bitmap > rendering shows po file headers
6 1318345 0 05/11 Masato HASHIMOTO untranslatable strings in trunk-r13348
12 1318532 0 05/12 Masato HASHIMOTO Extension/Guides creator: Render fails
3 1247448 0 05/10 bcrowell INKSCAPE_PORTABLE_PROFILE_DIR should be on man page
3 1317140 0 05/09 jazzynico Tutorials: supported generic font names in trunk have changed
3 1318328 0 05/11 Masato HASHIMOTO typo in trunk-r13348
3 1318671 0 05/12 Masato HASHIMOTO url for New in This Version is obsolete
3 1314910 0 05/01 Claus Johansen Font size specification
Total Score: 99 / 1500
Scoring:
--------
12, 9, 6, 3 for importances critical, high, medium and low
+1 point per year of the bug report's age
x2 if bug is tagged 'regression'
x2 if closed the week it was declared Bug of the Week
Bug of the Week
---------------
Ryan Lerch closed 30 points worth of bugs, due to hammering our
tutorials into shape. Ryan, would you please find us a good Bug of the
Week for May 12-18?
Bryce
8 years, 11 months
Running Screen
by Jabiertxo Arraiza Cenoz
Hi to all.
I dont know if this are discussed previously, but whats your opinion of
a loading/running screen for inkscape?
Regards, Jabier.
8 years, 11 months
Fw: how to submit tutorials for official documentation?
by Brynn
Hi again,
Also for item 4.2, under "Development (no coding needed)" > Mockup new
dialogs. This is a good one, because I've seen questions about this in
forums. No one seems to know where to submit such new dialog mockups. I
might guess, the dev mailing list, but not sure. If you could tell me
where/how, I'll include that :-)
And in that same section, > Add Extensions. I can say that it has been
frustrating trying to guide people (in forum topics) who want to learn how
to write extensions. If anyone could write a tutorial for that, or at least
a brief guide, I think it would be very helpful, and as well, perhaps result
in more new extensions. (Same for filters, although that's another story.)
As I mentioned earlier, related to updating the FAQ (in an older msg), I'll
be making a list of needed documentation (afa the faq). So I'll include
this in the list. No one really answered, when I asked to whom I should
send such a list. I know you said Tav is the point guy for the manual. But
for other documentation, who should I contact? Also Tav?
Thanks again :-D
brynn
--------------------------------------------------
From: "Brynn" <brynn@...3133...>
Sent: Saturday, September 27, 2014 11:08 PM
To: "Inkscape-Devel" <Inkscape-devel(a)lists.sourceforge.net>
Subject: [Inkscape-devel] how to submit tutorials for official
documentation?
> Hi Friends,
> For item #4.2 of the FAQ ("Are there non-coding ways to help?")
> under Help Fellow Users > Write Tutorials, I want to include info on how
> to
> submit tutorials for the official documentation. Or at least provide a
> link
> to such info. (Also, I might want to contribute tutorials myself.)
> So far, all I've found is this page
> http://wiki.inkscape.org/wiki/index.php/User_manual_information, which I'm
> not sure is even a relevant doc anymore. It says to subscribe to the Inks
> Docs mailing list, but other links are dead (not found).
> Is there any other info, that I haven't found yet? Or is
> subscribing to the list, pretty much all that's needed (and then tutorial
> writers will find out how to submit them, from the mailing list)?
> Thanks for your help :-)
> brynn
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
8 years, 12 months
another updating faq question (how to open CDR files)
by Brynn
Hi Friends,
Another FAQ item which doesn't seem to make sense, and that I'm not
familiar with -- How to open CDR files. (Currently item 6.8 but will be
moved in updated faq). Here's what it says now:
____________________
You can use UniConvertor for converting CDR files and some other formats to
SVG. In Inkscape 0.46+, there's an input extension that will allow you to
open or import CDR files directly from Inkscape if you have UniConvertor
installed on your system.
If you can't run UniConvertor, you can try this workaround:
1 - Open the CDR file in Corel Draw. Save it as a binary encoded CGM* file.
It will save only vector graphics. It will not save bitmap graphics.
2 - Open the CGM file in OpenOffice Impress. Copy to Open Office Draw and
insert original JPG or another bitmap graphics. Save file as ODG And you can
continue in Open Office Draw program.)
3 - Select all (CTRL+A)
4 - Export as SVG.
5 - Open SVG file in Inkscape and correct mistakes if they appear.
Note: OpenOffice will open only binary encoded CGM files in Impress. If the
CGM is encoded using clear-text encoding, it will be opened in OpenOfice
Writer, thus rendering the next steps invalid.
____________________
It's the workaround that's not making sense. #2 about inserting
JPG -- I might guess that maybe CDR files can contain both raster and vector
images?? But it's not clear at all. I mean, this workaround requires the
user to have Corel Draw, Open Office Impress, and OO Draw, all installed.
With all that, and they still need Inkscape? I'm not sure the workaround is
even worth keeping -- especially not if it's out of date. And there's a
close parenthesis which didn't have an open parenthesis. So I think
something has been edited incompletely.
However, if that's still a valid workaround, I'll keep it in place.
Would someone please give me a quick verdict on that? If worth keeping, any
edits needed?
Thank you so very much :-)
All best,
brynn
8 years, 12 months
