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, 5 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, 1 month
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.
7 years, 10 months
Making inkscape usable in valgrind grumble
by mathog
Hi all,
In order to find memory leaks, some types of access violations, and the
use of uninitialized variables I depend on valgrind. The problem is
that valgrind is barely usable with Inkscape. The output on even the
most minimal session (open, type a few letters, format them, close) runs
to just under 500K lines and takes 5 minutes to complete. Some of this
may be because garbage collection must be turned off in order to use
valgrind. That is:
export _INKSCAPE_GC=disable;
valgrind .... src/inkscape
There is no choice in that though, because if it is not done valgrind
crashes when it tries to run inkscape. (Ubuntu 12.10.4, 32 bit, current
Trunk). There is a libgc.supp in the top of the distribution, but it
cannot be used on my system, since it does not suppress valgrind's crash
when it tries to run inkscape with GC enabled.
Here is the damage seen on a normal exit for a minimal run:
==16527== LEAK SUMMARY:
==16527== definitely lost: 567,697 bytes in 17,670 blocks
==16527== indirectly lost: 2,167,402 bytes in 73,234 blocks
==16527== possibly lost: 21,940,610 bytes in 282,461 blocks
==16527== still reachable: 21,470,100 bytes in 360,304 blocks
What can be done so that Inkscape makes a better effort at cleaning up
its enormous memory tangle when it exits while running in valgrind?
Some of the memory Inksape allocates is cleaned up, but it seems like a
very high percentage of memory allocations are tacked into this complex
memory structure, and inside valgrind the whole ball of yarn is just
dropped on the floor when the program reaches the final exit(), rather
than being unwound in an orderly fashion. (In theory GC may be
cleaning this up better, but I'm not sure how we can really know, since
valgrind cannot tell us.)
Could somebody who understands these parts of Inkscape PLEASE clean up
this mess, so that in future when "_INKSCAPE_GC==disable" Inkscape will
unwind its memory structures before exiting? At the very least we will
learn after this unwinding what memory is still left, and that will be
the result of existing bugs in the code. Once we obtain a baseline
inkscape that is usable once again in valgrind, we can reasonably expect
that by using valgrind developers will be able to catch the memory
problems they may introduce. Sadly that is far from true now, what with
so many thousands of lines of background noise in the log files to slog
through.
Admittedly some of the lines in valgrind's log file do come from
valgrind issues, but the ones I know about can be removed with:
cat >wcslen_sse2.supp <<EOD
{
wcslen1
Memcheck:Addr8
fun:__wcslen_sse2
fun:*
}
{
wcslen2
Memcheck:Cond
fun:__wcslen_sse2
fun:*
}
{
iffyinflate
Memcheck:Cond
fun:inflateReset2
fun:inflateInit2_
obj:*
}
EOD
valgrind -v --leak-check=yes --leak-resolution=high --num-callers=15
--show-reachable=yes --suppressions=./wcslen_sse2.supp
--log-file=/tmp/vgfi.log src/inkscape
which improves the output to:
--16527-- used_suppression: 208319 wcslen1
--16527-- used_suppression: 142 wcslen2
--16527-- used_suppression: 330 iffyinflate
==16527==
==16527== ERROR SUMMARY: 97190 errors from 13437 contexts (suppressed:
208791 from 656)
I understand that there may be other problems in some libraries which
are called, but from the contents of the log file it looks like the
majority of the loose ends were directly created in Inkscape. (And we
can use valgrind suppression files, as above, to silence the unfixable
library problems.)
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
8 years, 9 months
Improved gears extension
by Jürgen Weigert
Just saw braingram's rack gear extension coming in. Nice work! Thank you.
But that reminds me that I also have a small contribution to share. Here is
an enhanced version of the gears plugin, please also consider this for
future inclusion
git@...2977...:jnweiger/inkscape-extensions-gears-dev.git
cheers, JW-
8 years, 10 months
Re: [Inkscape-devel] Bug Hunt for 0.91
by Bryce Harrington
Current stats:
Bug Hunt Goal: 500 points
Current: 381 points
Pts Bug Date Assignee Description
------------------------------------------------------------------------
9 1280684 2/22 Alvin Penner changing doc units with viewbox defined
9 1278645 2/22 David Mathog Image handling corrupts EMF/WMF output
9 1171109 2/20 insaner crash on cut n paste, or alt+scroll..
6 1258473 2/13 Alvin Penner trunk: ink2canvas for stroked objects fails
6 1250250 2/07 David Mathog WMF/EMF open misplaces drawing
9 168695 1/28 Martin Owens Crash when undoing while mouse button pressed
6 1272119 1/27 apenner Poor rendering after 2geom update
6 1268778 1/25 jazzynico Move cursor disappears
3 1266308 1/15 apenner bbox dotted lines not visible if overlapped
9 1256449 1/15 Tavmjong Bah Clipped groups lose clipping when exporting
6 1268778 1/15 JazzyNico Move cursor disappears
3 1239779 1/14 Martin Owens symbol preview no longer updates
6 1253110 1/12 Johan E. Wrong intersection on circles at 45° (rev >= 12594)
6 1251405 1/10 mathog btool hitting command line limit on XP/Mingw/Msys
9 1255791 1/10 Martin Owens crash drag deleting guides
9 1257417 1/09 Martin Owens crash removing ID from object
9 1230241 1/09 Martin Owens crash for text with empty font-family
9 1258815 1/08 Kris crash after using Edit nodes icon twice
3 1255764 1/08 Bryce on screen snap message says UNDEFINED
9 1192023 1/08 Martin Owens Use elements removed when grouping
9 168695 1/08 Martin Owens crash when undoing
6 1247324 1/06 Jabiertxof optimized transforms do not propagate
9 1265556 1/04 JazzyNico plain svg export broken for filter
3 1057494 1/04 JazzyNico text hidden with "Remove Manual Kerns"
6 1262146 1/04 apenner persistent offset when scaling object
On Tue, Jan 28, 2014 at 09:13:11PM -0800, Bryce Harrington wrote:
> Pts Bug Date Assignee Description
> ------------------------------------------------------------------------
> 9 168695 1/28 Martin Owens Crash when undoing while mouse button pressed
> 6 1272119 1/27 apenner Poor rendering after 2geom update
> 6 1268778 1/25 jazzynico Move cursor disappears
>
> 3 1266308 1/15 apenner bbox dotted lines not visible if overlapped
> 9 1256449 1/15 Tavmjong Bah Clipped groups lose clipping when exporting
> 6 1268778 1/15 JazzyNico Move cursor disappears
> 3 1239779 1/14 Martin Owens symbol preview no longer updates
> 6 1253110 1/12 Johan E. Wrong intersection on circles at 45° (rev >= 12594)
> 6 1251405 1/10 mathog btool hitting command line limit on XP/Mingw/Msys
>
> 9 1255791 1/10 Martin Owens crash drag deleting guides
> 9 1257417 1/09 Martin Owens crash removing ID from object
> 9 1230241 1/09 Martin Owens crash for text with empty font-family
> 9 1258815 1/08 Kris crash after using Edit nodes icon twice
> 3 1255764 1/08 Bryce on screen snap message says UNDEFINED
> 9 1192023 1/08 Martin Owens Use elements removed when grouping
> 9 168695 1/08 Martin Owens crash when undoing
> 6 1247324 1/06 Jabiertxof optimized transforms do not propagate
>
> 9 1265556 1/04 JazzyNico plain svg export broken for filter
> 3 1057494 1/04 JazzyNico text hidden with "Remove Manual Kerns"
> 6 1262146 1/04 apenner persistent offset when scaling object
>
> Bryce
>
>
> > Pts Bug Date Assignee Description
> > ------------------------------------------------------------------------
> > 3 1266308 1/15 apenner bbox dotted lines not visible if overlapped
> > 9 1256449 1/15 Tavmjong Bah Clipped groups lose clipping when exporting
> > 6 1268778 1/15 JazzyNico Move cursor disappears
> > 3 1239779 1/14 Martin Owens symbol preview no longer updates
> > 6 1253110 1/12 Johan E. Wrong intersection on circles at 45° (rev >= 12594)
> > 6 1251405 1/10 mathog btool hitting command line limit on XP/Mingw/Msys
> >
> > 9 1255791 1/10 Martin Owens crash drag deleting guides
> > 9 1257417 1/09 Martin Owens crash removing ID from object
> > 9 1230241 1/09 Martin Owens crash for text with empty font-family
> > 9 1258815 1/08 Kris crash after using Edit nodes icon twice
> > 3 1255764 1/08 Bryce on screen snap message says UNDEFINED
> > 9 1192023 1/08 Martin Owens Use elements removed when grouping
> > 9 168695 1/08 Martin Owens crash when undoing
> > 6 1247324 1/06 Jabiertxof optimized transforms do not propagate
> >
> > 9 1265556 1/04 JazzyNico plain svg export broken for filter
> > 3 1057494 1/04 JazzyNico text hidden with "Remove Manual Kerns"
> > 6 1262146 1/04 apenner persistent offset when scaling object
> >
> >
> > On Fri, Jan 10, 2014 at 01:11:57PM -0800, Bryce Harrington wrote:
> > > Quite a busy week! Another 63 points worth of bugs squished:
> > >
> > > 9 1255791 2014-01-10 Martin Owens crash drag deleting guides
> > > 9 1257417 2014-01-09 Martin Owens crash removing ID from object
> > > 9 1230241 2014-01-09 Martin Owens crash for text with empty font-family
> > > 9 1258815 2014-01-08 Kris crash after using Edit nodes icon twice
> > > 3 1255764 2014-01-08 Bryce on screen snap message says UNDEFINED
> > > 9 1192023 2014-01-08 Martin Owens Use elements removed when grouping
> > > 9 168695 2014-01-08 Martin Owens crash when undoing
> > > 6 1247324 2014-01-06 Jabiertxof optimized transforms do not propagate
> > >
> > > Inkscape's changelog for this past week shows a lot more awesome cleanup
> > > work underway that doesn't show up on this list, including warnings
> > > fixes and translation updates.
> > >
> > > Bryce
> > >
> > > > Today three more regression bugs were fixed:
> > > >
> > > > 9 1265556 2014-01-04 JazzyNico plain svg export broken for filter
> > > > 3 1057494 2014-01-04 JazzyNico text hidden with "Remove Manual Kerns"
> > > > 6 1262146 2014-01-04 apenner persistent offset when scaling object
> > > >
> > > > Bryce
> > > >
> > > > On Sun, Dec 29, 2013 at 04:15:54PM -0800, Bryce Harrington wrote:
> > > > > Welcome to the first bug hunt for the 0.91 release. This hunt focuses
> > > > > on regression bugs.
> > > > >
> > > > > Traditionally, we specify a point target for us to reach, and award us
> > > > > points based on the severity of the bug: 3, 6, 9, or 12 points for low,
> > > > > medium, high, and critical. This bug hunt's goal is 500 points worth of
> > > > > bugs from the following list:
> > > > >
> > > > > http://tinyurl.com/bughunt91a
> > > > >
> > > > > You'll note a few dozen regressions were already fixed, so we'll count
> > > > > that as a (207 point) headstart on the effort. Here's a couple more
> > > > > links to list only the open or closed bugs:
> > > > >
> > > > > http://tinyurl.com/bughunt91a-open
> > > > > http://tinyurl.com/bughunt91a-closed
> > > > >
> > > > > [I'll write a launchpadlib script to calculate the score from the latter
> > > > > list, unless someone's ambitious and beats me to it!]
> > > > >
> > > > > We only give points for true bug fixes - not bugs simply closed due to
> > > > > being dupes, invalid, works-for-me, or whatnot. Once the bug is fixed
> > > > > in the mainline branch, set its status to Fix Committed, and it'll tally
> > > > > as a fixed regression.
> > > > >
> > > > > Bug Hunt Goal: 500 points
> > > > > Current: 207 points
> > > > >
> > > > > If you're not a developer, you can still help by seeing if you can
> > > > > reproduce the bug yourself, and posting your findings.
> > > > >
> > > > > If you have an idea on how to fix the bug, but don't have the time to do
> > > > > it yourself, then outlining your thoughts on the bug may help junior
> > > > > developers pick it up and implement the changes.
> > > > >
> > > > > If you're an experienced developer, consider posting an invitation to an
> > > > > IRC bug party for the time period you'll be working, if you're willing
> > > > > to help pilot junior developers and sponsor their patches.
> > > > >
> > > > > I will be posting scoring updates a couple times a week until we're
> > > > > done.
> > > > >
> > > > > Bryce
> > > > >
> > > > > ------------------------------------------------------------------------------
> > > > > 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
> > > >
> > > > ------------------------------------------------------------------------------
> > > > 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
> > >
> > > ------------------------------------------------------------------------------
> > > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > > Critical Workloads, Development Environments & Everything In Between.
> > > Get a Quote or Start a Free Trial Today.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Inkscape-devel mailing list
> > > Inkscape-devel(a)lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> >
> > ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Inkscape-devel mailing list
> > Inkscape-devel(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
9 years
Ungrouping switches
by Krzysztof Kosiński
This is related to https://bugs.launchpad.net/inkscape/+bug/1001756
The ungrouping code was treating svg:switch like groups. Is this the
correct behavior? (For the time being, I modified it to ignore
groups.)
We don't use svg:switch in Inkscape-generated SVG at the moment, so
this is relevant only to externally authored content.
Regards, Krzysztof
9 years
Viewport, filters, and Inkscape code structure: help needed
by Tavmjong Bah
I am struggling a bit with the overall structure of Inkscape's code as I
work on getting filter regions implemented correctly. This is how I
understand the current structure to work:
XML Tree:
This represents the actual document.
SP Tree:
This is an expanded tree. For example:
<defs>
<rect id="myRect"/>
</defs>
<use xlink:href="#myRect"/>
has two SPRect instances, one for the <rect> in the <defs> section
and one generated by the <use> element. The allows for things such as
style cascading and for different dimensions when the rectangles size is
expressed in percent of the viewport (and there are multiple viewports
in one document).
Markers and symbols may also have multiple instances generated.
The SP tree includes print functions used by the EMF, WMF, and TeX
exporters. Other exporters (including Cairo PDF and PS) are independent
of the SP and NR trees.
NR Tree (e.g. Cairo Renderer):
This is an expanded tree created for on-screen rendering.
(Silly questions: what does NR mean?, what does 'arena' mean?)
Now we come to filters. A filter can be applied to multiple objects.
It's coordinates can be expressed in terms of the current viewport or
the bounding box of the object that references it. In both cases, a
filter's absolute coordinates can be different when applied to different
objects. At the moment, only the bounding box case is handled and it is
handled in the NR Tree. The NR tree doesn't know about the viewport but
the SP tree does so I've tried to add code to handle the coordinates
expressed in terms of a viewport into the SP tree. It seems more natural
to handle coordinates in the SP tree as the SP print functions and other
exporters can take advantage of these dimensional calculations. This
works, kind of. There are a couple of problems:
1. The update functions of the filter primitives are not called.
This can be fixed by adding explicit calls from SPFilter::update
(following the model in the SPGroup update function).
2. The filter update function is only called once, at the beginning
of the update process. So if a document has more than one viewport (due
to an embedded SVG, for example), the filter coordinates are not updated
for the second viewport. (This is unlike the <use> element case.)
It seems my choices for fixing filter regions for viewport based
dimensions is to either follow the <use> element example, and have
instances of the filter element for each use of the element or to move
all coordinate handling to the NR tree (after making the viewport
available in the NR tree). The former, I think, is more desirable, but
the latter may be easier.
Any thoughts?
Thanks,
Tav
9 years
Casting-macro replacement
by Markus Engel
Hi there,
in r13061 I added two template functions in order to replace the tools'
casting macros.
You can see them in action in widgets/pencil-toolbar.cpp:110.
I also added some compile-time checking there which can be uncommented
later.
As I just stumbled across this. In order to build clang from its svn source,
you need a c++11-enabled compiler:
"This is expected to be the last release of LLVM which compiles using a
C++98 toolchain. We expect to start using some C++11 features in LLVM and
other sub-projects starting after this release. That said, we are committed
to supporting a reasonable set of modern C++ toolchains as the host compiler
on all of the platforms. This will at least include Visual Studio 2012 on
Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux. The final set of
compilers (and the C++11 features they support) is not set in stone, but we
wanted users of LLVM to have a heads up that the next release will involve a
substantial change in the host toolchain requirements."
Should I proceed replacing the casting-macros like this? Any suggestions?
Regards,
Markus
9 years
Swatch dialog has a serious bug
by Johan Engelen
Hi all,
I just discovered a very serious bug in the swatches dialog
(/src/ui/dialog/swatches.cpp). Using a vector of DocTrack*, it tracks
all current documents, and using a timer callback updates itself. The
problem is, no DocTrack* is ever removed from that list.
A DocTrack* (that points to an SPDocument) is added whenever you open a
new document. Then when closing a 2nd document, the DocTrack* should be
removed from the list and ~DocTrack should be called. Because this is
_not_ happen, the timerfunction will use an already deleted SPDoc and
will eventually crash in SPDocument::getResourceList (priv is set to
nullptr for deleted SPDoc).
I added proper ref-counting of the SPDoc object in DocTrack's
constructor and destructor, but still the SPDoc is deleted and the crash
occurs.
Some code in swatches.cpp looks unfinished, creating data structures
that are never used...
Thanks for any help in tracking down and fixing the issue,
Johan
9 years
