And the winner (by quite a bit, actually) is Euphoria Script!
Thanks to everyone for the votes and helping us choose a new open font.
The new font will be deployed to the website and relevant graphics.
You can start using it now in your inkscape-related materials by
downloading it here:
(includes font and ofl license files).
Have fun, and thanks again for the help!
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
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
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
6.72 57.32 4.44 563 0.01 0.01
5.51 60.96 3.64 1216 0.00 0.00
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
std::allocator<Geom::Path> > const&, Geom::Affine const&)
0.06 65.30 0.04 8 0.01 0.01
0.05 65.33 0.03 885444 0.00 0.00
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
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?
I initially asked at
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
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.
In the past several months - closer to a year, actually - I've used Inkscape
in a tight production environment almost daily. I have produced hundreds
of illustrations for a computer-based technical course. During that period
I used Inkscape 0.48.5 and lately switched to test builds and release
candidates of 0.91. All of this time I have kept a list of the problems I ran
into using Inkscape. Some are plain bugs, some are more complex problems for
which I have no idea for a solution. After testing the new version to see
whether some of these problems have gone away, I thought I might share this
document with you.
Before I go on, I just like to say that these are mostly minor points. I am
an avid user and promoter of Inkscape even though my workplace has provided
me with a legal copy of Adobe Illustrator, which I think is inferior in
ease of use. I think Inkscape on the whole is a brilliant piece of software
and I'm thankful for all your efforts. But some problem just kept popping up
again and again.
So without further ado, here's the document (it's a google doc):
Thank you for any comment or feedback you might have.
- Michael Grosberg
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
> > used to reproduced the bug were all using an Intel GPU. Tests with an
> > 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-126.96.36.199z),
> 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.
My friend has just complained that Inkscape doesn't have colour mixing.
He's the first person to mention this functionality to me and I believe
from his description the idea is that the colours can be mixed off
canvas, where two color stops are selected and then a slider can move
between the two.
Has anyone ever heard of this?
Best Regards, Martin Owens
I would like to convert a path that internally stores EllipticalArcs into a path with a bunch of BezierCurves. Is there a method that already does this? One way I think can be used is to convert path to pwd2, and convert back again to pathVector using path_from_piecewise() because internally it only uses Bezier curves, but I am wondering if there is a more direct way to do this.
If I have a PathVector structure, and I know all Paths inside are connected to each other, is there an easy way to convert such PathVector into Path?
Papoj "Hua" Thamjaroenporn
Jenkins, our CI system, has been down for more than a month. It looks
like the disk has filled up, and we need to do clean up / the build
tasks should clean up after themselves better (I suspect it has to do
with storing the results of too many older builds instead of just the
current one plus a few recent builds).
We need an administrator for Jenkins. Currently, I think only me and
Bryce have access, which is not good enough.
Who is interested in maintaining the automatic build/testing system?
Of course, you can tailor the system to your own likes; there is much to
be improved and I think all are open to whatever crazy plans you may
Because of hardware problems with my main PC tower I went to my laptop where Inkscape 0.91 stable was installed while I mainly use Trunk usually. I noticed a difference in size in cut and paste from FontForge (the version 2 from Ubuntu 14.04 repositories) between Trunk and Stable 0.91. And I don't know if this is due to changes in units in Inkscape, and intentional or not. Thus I hesitate to fill a bug. However I will fill it if necessary. I ask me also if some settings I changed in my Trunk could cause this change.
- if I cut a glyph in FF and paste it in Inkscape Trunk, its size in Inkscape is equivalent to this glyph typed at 750 pts
- if I do the same to Inkscape Stable it's equivalent to the same at 800 pts