~suv-2 wrote:
The initial message of the thread I linked to earlier gives the revision number when libnr was removed:
Ok, thanks. I hoped not to have to go so much backward but indeed rev 10588 works as expected. Unfortunately, I'll have some difficulties in checking and appreciating Diederik's progresses (I've read "3) groundwork for tangential/perpendicular snapping" in rev 10672 comment :)
Krzysztof Kosiński wrote:
The problem is a bit deeper. There was a lot of code that used the "approximate" bounding box, which is not well defined, but roughly corresponds to the visual bounding box and is easy to calculate. I changed most code that used approximate bbox (which was the default) to use the visual bbox and removed the default value from methods that take a bounding box type, to force people to specify which kind of box they mean. As I worked through the code it became apparent that a lot of it is wrong and should use the geometric box, but this could cause regressions.
Does this mean that there's still a lot of work left before seeing a correct management of visual/geometric bounding box? If so, why not still keeping the quick "approximate" bounding box (at least for now) that worked so well instead of forcing the use of the much heavier visual one in all those cases where it's not really needed? Implementations would still remain wrong until they are corrected to use the geometric one. If I correctly understood the problem, of course.
What I surely didn't understand is why the overload rises with the number of objects present in the drawing: if I have a lot of rectangles, moving a single one is a pain while it's not when I have only a couple. I can't catch the relationship with the complexity of bounding box calculation (and, anyway, we are speaking of rectangles...).
Regards. Luca