Node tool can't manipulate nodes dependent on zoom when LPE applied

[ScislaC]

It's probably a poor description as it seems like a really broken path, but it's odd that the strange behavior appears to be more of an issue depending on zoom.

Attached is a file that demonstrates the issue.

1) Open the document
2) Select the object
3) Switch to node tool and hover over nodes (as if you are going to select)
3) Try to interact with nodes (not LPE handles)

If at a zoom of 281% or higher, node can't be selected. Zoomed out 280% or lower seems to be okay.

[ScislaC (scislac)]

It was with r13401 experimental (a recent copy of trunk also exhibited it).

[Liam P. White (liampwhite)]

Confirmed on Linux and Windows (both GTK 3).

[Liam P. White (liampwhite)]

Fix committed in r13427 lp:inkscape/experimental, 13447 lp:inkscape.

@Johan -
Can you add some safety checks to the Piecewise class in 2geom, so that out-of-bounds accesses will at least print a warning? The points being accessed with this particular path were on a diversion course headed straight for LONG_MIN.

[Liam P. White (liampwhite)]

@ScislaC: how was this SVG file produced?

Warnings with new safety check (canvas remains manipulable at all zoom levels):

** (inkscape:4341): WARNING **: Broken powerstroke point at 358.000000, I won't try to add that
** (inkscape:4341): WARNING **: Broken powerstroke point at 317.555850, I won't try to add that
** (inkscape:4341): WARNING **: Broken powerstroke point at 309.271980, I won't try to add that
** (inkscape:4341): WARNING **: Broken powerstroke point at 358.000000, I won't try to add that
** (inkscape:4341): WARNING **: Broken powerstroke point at 317.555850, I won't try to add that
** (inkscape:4341): WARNING **: Broken powerstroke point at 309.271980, I won't try to add that

[Liam P. White (liampwhite)]

How I discovered the cause of the bug:

lp:~inkscapebrony/inkscape/inkscape has a powerstroke width dialog. Zooming in and Shift+clicking the canvas as if it were a powerstroke knot caused the width handler to appear. Also, runs in gdb revealed that at high zoom, sp_knot_handler was being called for every single canvas event when it shouldn't have; calling sp_canvas_item_hide from within gdb made the problem go away.

Why the bug happened:

When an SPCanvasItem is assigned a ridiculous value (such as the ones that would be obtained by a diverging function), it seems to overflow into other values into the struct and/or take up all available space on the canvas (bug!)