← Back to team overview

kicad-developers team mailing list archive

Re: RTree implementation


On 06/08/18 18:35, Seth Hillbrand wrote:
> There's another 32-bit RTree issue that is showing its face
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905221).  The last
> one (https://bugs.launchpad.net/kicad/+bug/1774316), we hacked around
> for v5 but as this seems to be a recurring theme, I'd like to address it
> with some finality.
> We could maintain the RTree implementation ourselves with updates to
> correct these errors.
> Or, we could use the Boost-based implementation
> (https://www.boost.org/doc/libs/1_67_0/libs/geometry/doc/html/geometry/reference/spatial_indexes/boost__geometry__index__rtree.html).
> I have a basic framework for shifting to the Boost-based
> implementation.  In tests, I don't see a speed difference in running. 
> Compiling might be modestly slower.

Hi Seth,

I would be careful with anything related to geometry in Boost. Good
things from Boost sooner or later end up in the standard C++ library
(e.g. unordered). We had a lot of trouble in the past with crashes in
boost::polygon that nobody could debug or even understand because of the
vast complexity of Boost code. We struggled for few months to replace it
with Clipper, since then, we've seen no crashes in polygon boolean ops.

If the solution to fix the current R-tree to work on 32-bit platforms is
to use doubles instead of floats, why not try it out? By changing to
boost::geometry, we'll likely have to report bugs there. I'm also quite
surprised this bug surfaced on one particular OS (Debian) 5 years after
this R-tree implementation had been introduced to pcbnew. Does anyone
here know why it crashes on Debian and not on other 32-bit systems?


Follow ups