Hi. I&#39;m using Inkscape to author a comic and the slow speed for certain things is very annoying. I&#39;m already have OpenMP turned on and using 4 cores.<div><br></div><div>1. <b>large blurs are slow</b> - I&#39;m an expert with writing SIMD code, so I was thinking about vectorizing the Gaussian IIR filter with SIMD intrinsics, even though it&#39;s harder than for a FIR. But I noticed there isn&#39;t any SIMD code in Inkscape so does that mean it&#39;s something to avoid.</div>
<div>I&#39;m pretty sure no current compiler is smart enough to vectorize it, and besides, Inkscape is compiled with -O2, meaning -ftree-vectorize isn&#39;t on by default.</div><div><br></div><div><br></div><div>2. <b>when there&#39;s a large image (raster based) background - scrolling in a zoomed region is very slow</b></div>
<div>I compiled the latest 0.49 code with GCC profiling and it shows this:</div><div><br></div><div><div> 33.98     22.47    22.47                             exp2l</div><div> 21.29     36.55    14.08                             log2l</div>
<div> 17.57     48.17    11.62                             pow</div><div>  7.12     52.88     4.71      658     0.01     0.01  ink_cairo_surface_srgb_to_linear(_cairo_surface*)</div><div>  6.72     57.32     4.44      563     0.01     0.01  ink_cairo_surface_linear_to_srgb(_cairo_surface*)</div>
<div>  5.51     60.96     3.64     1216     0.00     0.00  Inkscape::Filters::FilterGaussian::~FilterGaussian()</div><div>  5.23     64.42     3.46                             internal_modf</div><div>  0.59     64.81     0.39                             _mcount_private</div>
<div>  0.41     65.08     0.27                             __fentry__</div><div>  0.12     65.16     0.08                             GC_mark_from</div><div>  0.09     65.22     0.06     5579     0.00     0.00  Geom::parse_svg_path(char const*, Geom::SVGPathSink&amp;)</div>
<div>  0.06     65.26     0.04    35320     0.00     0.00  bounds_exact_transformed(std::vector&lt;Geom::Path, std::allocator&lt;Geom::Path&gt; &gt; const&amp;, Geom::Affine const&amp;)</div><div>  0.06     65.30     0.04        8     0.01     0.01  convert_pixbuf_normal_to_argb32(_GdkPixbuf*)</div>
<div>  0.05     65.33     0.03   885444     0.00     0.00  std::vector&lt;Geom::Linear, std::allocator&lt;Geom::Linear&gt; &gt;::_M_fill_insert(__gnu_cxx::__normal_iterator&lt;Geom::Linear*, std::vector&lt;Geom::Linear, std::allocator&lt;Geom::Linear&gt; &gt; &gt;, unsigned long long, Geom::Linear const&amp;)</div>
<div><br></div></div><div><br></div><div>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?</div>
<div>Why not convert the images up front to linear and stay that way in memory?</div><div><br></div><div>If that can&#39;t be done, then my optimization approach is:</div><div>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 &lt; 10, it uses simple scaling.</div>
<div><br></div><div>2. replace ink_surface_linear_to_srgb()  with  a vectorized implementation of pow(). Unlike srgb_to_linear(),  a low degree polynomial can&#39;t be used due to the curve having larger high order derivatives. An alternative would be piece wise, low order polynomials.</div>
<div><br></div><div>The main question I have is what degree of accuracy is desired? Certainly, it doesn&#39;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?</div>
<div><br></div><div><br></div><div> UJ</div><div><br></div>