Rotational node-snapping to path fails with rev >= 14226

[su_v]

Rotating a shape (or path) and snapping e.g. with its cusp nodes to a path fails in current trunk (affects select as well as node tool context).

Steps to reproduce:
1) launch trunk (default prefs, default new doc)
2) enable 'Snap to paths'
3) draw a slanted straight line (2 nodes)
4) draw a square from center (press 'Shift+Ctrl'); for the center point, snap to one of the endpoints of the line
5) rotate the square until one of the corners snaps to the line
--> fails to snap
6) convert straight line to guide ('Shift+G')
7 repeat step 5
--> snapping a corner to the slanted guide works as expected

First noticed with Inkscape 0.91+devel r14267 on OS X 10.7.5.

Based on tests with archived builds:
- not reproduced with 0.91+devel rev <= 14224,
- reproduced with 0.91+devel rev >= 14228;
this regression seems likely related to the recent 2geom update:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/changes/14228
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14226

[Diederik van Lierop (mail-diedenrezi)]

Fixed as of rev. #14411

[su_v (suv-lp)]

Backported from Inkscape trunk r14411 to lib2geom in rev 2465.

[su_v (suv-lp)]

@Diederik - if you have some time to spare, maybe you could take a look at the attached reduced test case of a crash I encountered repeatedly while working on a drawing with current trunk (r14492 on OS X 10.7.5)?

Steps to reproduce:
1) launch trunk with test case
2) select the group with the blue and red triangle
3) switch to rotation handles
4) grab upper right rotation handle and drag clockwise around the group's rotation center
At this point, trunk usually crashes for me, or at the latest when rotating back (CCW) after having rotated past the horizontal line.

Please let me know if you would prefer a separate report …

[su_v (suv-lp)]

Backtrace with debug build (r14476).

[Diederik van Lierop (mail-diedenrezi)]

The tolerances used in 2Geom::EllipticalArc::_filterIntersections() are apparently a bit too tight, triggering the asserts. If I change both tolerances from 1e-6 to 1e-5 then everything works as expected:

void EllipticalArc::_filterIntersections(std::vector<ShapeIntersection> &xs, bool is_first) const
{
    Interval unit(0, 1);
    std::vector<ShapeIntersection>::reverse_iterator i = xs.rbegin(), last = xs.rend();
    while (i != last) {
        Coord &t = is_first ? i->first : i->second;
        assert(are_near(_ellipse.pointAt(t), i->point(), 1e-5));
        t = timeAtAngle(t);
        if (!unit.contains(t)) {
            xs.erase((++i).base());
            continue;
        } else {
            assert(are_near(pointAt(t), i->point(), 1e-5));
            ++i;
        }
    }
}

I'll have to check with Krzysztof though if this is OK.

[Krzysztof Kosinski (tweenk)]

These thresholds are rather arbitrary and probably should be removed.

Also, another 2Geom sync is in order, since I made some significant bugfixes to the intersection routines.

[Diederik van Lierop (mail-diedenrezi)]

Thanks Krzysztof!

Will you take care of the 2Geom sync?