several actions outputs to the terminal: "warning: invalid state when picking..."

[Cojnel]

The terminal keeps outputting
** (inkscape:11810): WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4

as one works with inkscape
it's most noticeable when dragging out a gradient,
moving the first or last gradient stops,
or erasing an unselected object with the
touch deletion setting on the eraser.

It also happens but not as often when
moving an object, path or node handle,
or drawing, scaling or rotating a shape.

Tested with:
r12833 on linux mint 15 cinnamon 32bit

= Steps to Reproduce =
1. draw two paths.
2. activate the node editing tool.
3. turn on cusp node snapping.
4. select one of the paths.
5. snap a node from one of the paths to a node on the other path and release the mouse button.
6. start holding down the left mouse button on the node we just snapped,
    drag it away from where we snapped it,
    at least 5px (the default distance to detect dragging)
    now snap it back to where we started dragging it from,
    (it seams to happen more often if the cursor is
    moved over or close to the node that's being snapped to),
    release the mouse button.
7. the following actions causes the terminal to output the warning message:
    "** (inkscape:20946): WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4"

[su_v (suv-lp)]

 Mentioned earlier in
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/41660/focus=41790>

[Cojnel (cojnel)]

Clicking to select a path or shape stops working and the terminal outputs alot of
"...warning **: invalid state when picking..." messages after following these steps.

1. draw two paths.
2. activate the node editing tool.
3. turn on cusp node snapping.
4. select one of the paths.
5. snap a node from one of the paths to a node on the other path and release the mouse button.
6. start holding down the left mouse button on the node we just snapped,
    drag it away from where we snapped it,
    at least 5px (the default distance to detect dragging)
    now snap it back to where we started dragging it from,
    (it seams to happen more often if the cursor is
    moved over or close to the node that's being snapped to),
    release the mouse button.
7. the following actions causes the terminal to output the warning message:
    "** (inkscape:20946): WARNING **: Invalid state when picking: STATE_BBOX = 0, STATE_PICK = 4"

When the node tool is active and the mouse pointer is moved on
the drawable area of the inkscape window,
for every pixel moved, the terminal shows 3 or 6 warning messages,

When the select tool is active and the mouse pointer is moved within
5 pixels or inside the bounding box of a path/shape,
for every pixel moved, the terminal shows 3 warning messages,

When the right button context menu appears, the terminal shows 3 warning messages.

While this is happening it's not possible to click on a path or shape to select it,
but rubberband selecting works.

With the selection tool active, clicking on a rubberband selected object
to show it's rotation handles doesn't work either.

Here are some of the things i've tried that
does and does not turn off the warning messages
and bring back clicking on objects to select them.

No change:
turning snapping on or off.
pressing the select all button.
deleting all guides.
raising or lowering an object.
saving.
copying.

These actions bring back clicking to select
and the warning messages stop:
zooming in or out.
moving.
scaling.
rotating.
flipping horizontally and vertically.
drawing a new object.
adding text.
dragging out a guide.
duplicating.
changing fill or stroke color.
changing opacity.
pressing undo.
adding a new layer.
cutting.
pasting.
applying a filter.
live previewing or applying an extension.

The same thing as in the 7 steps above also happens if one,
scales or rotates a path or shape to a path or shape,
for example two rectangle shapes.

It doesn't just apply to end nodes on paths either,
it also happens with smooth nodes to intersections.

Tested with r12881 in linux mint 15 cinnamon 32bit
It does not happen in v0.48.4 r9939

[Bryce Harrington (bryce)]

Bumping up priority a notch because while this bug is in effect, the objects aren't clickable, so usability is impacted. The workarounds work but aren't immediately obvious.

[Krzysztof Kosinski (tweenk)]

The cause of this bug is that the update() function is not called before calling the pick() function on Inkscape::Drawing.

[Diederik van Lierop (mail-diedenrezi)]

Confirmed, thanks for directing me here ~suv!

This behavior is also invoked when trying to scale a vertical line in horizontal direction, or vice versa, but only when using a geometric bounding box. Upon releasing the mouse button after moving the arrow-shaped anchor, Inkscape starts spitting out these warning messages and no other object can be selected. As mentioned above, zooming reset the behavior back to normal

When using a visual bounding box though, the vertical line just moves in horizontal direction. This is also new behaviour...

[Diederik van Lierop (mail-diedenrezi)]

Sorry, but I accidentally set the status back to "confirmed". Can't set it back to "triaged"

[Diederik van Lierop (mail-diedenrezi)]

My method to reproduce was not complete apparently: in addition, it is required to have more than just a single object in your drawing... very weird.

[Diederik van Lierop (mail-diedenrezi)]

Krzysztof,

you're right about DrawingItem::update() not being called in time. I've found that I can work around this by fixing some stuff in the selector tool, by avoiding unneccesary applications of identity affines, and by avoiding NOOP undo logging. I still believe that I should call DrawingItem::update() explicitly, and not wait for the SPCanvasImpl::idle_handler to do this for me at some point. This would make everything more robust, because the next time someone changes the code of the selector tool things might break again.

What's the best way to call DrawingItem::update() explicitly, and where should I do this?

BTW, I've only studied my own bug report so far;. I haven't looked into Cojnel's report yet

[Krzysztof Kosinski (tweenk)]

The best way is to obtain a reference to Inkscape::Drawing, and call update() on it. If you use it before PICK, you should call it as:

drawing.update(Geom::IntRect::infinite(), UpdateContext(), DrawingItem::STATE_PICK);

Calling update() with all default parameters will also work, but may do unnecessary stuff in the future. If you have a pointer to SPDesktop, you can obtain a reference to Inkscape::Drawing this way:

Inkscape::Drawing &drawing = SP_CANVAS_ARENA(desktop->getDrawing())->drawing;

[Diederik van Lierop (mail-diedenrezi)]

I believe that this has been fixed as of rev. 13333.

Krzysztof, the fix was slightly different though; it was not the "pick state" that was out-of-date, but the bounding box. Also, drawing->update() was already being called just before arena->drawing.pick, in sp_canvas_arena_point(). So I just changed the update() call to also update the bounding box, so

- arena->drawing.update(Geom::IntRect::infinite(), arena->ctx, DrawingItem::STATE_PICK);
+ arena->drawing.update(Geom::IntRect::infinite(), arena->ctx, DrawingItem::STATE_PICK | DrawingItem::STATE_BBOX);

This does not fit well though with the model of updating stuff in the idle handlers, I believe. We're now updating the bounding box explicitly, whereas this could likely have been done earlier if the selector tool (or node tool) would have put this on the idle stack, and if the idle stack was working properly. I'm not sure if the latter is the case though. Let me explain:

1) The selector tools does a requestDisplayUpdate()
2) This allows the bounding box to be invalidated for the relevant items, when _updateDocument() is called in the sp_doc_idle_handler. This also sets need_update to true
3) If needs_update is true, then _updateItem will be called on the DrawingItem, which is all executed in another idle handler: the one of SPCanvasImpl.

Could it be that 3 is called before 2, i.e. SPCanvasImpl::idle_handler is called before sp_doc_idle_handler, and that this is the reason why the bounding box has not yet been updated? This is very tricky to get a grasp of, with all those different signals and functions being called. And if I would get to understand it at some point, then I'm by still not familiar enough with the Inkscape architecture to understand how this all should work instead and what must be changed.

BTW, I've fixed the selector tool to work regardless of this more general drawing->update() fix, but I've not touched your node tool code. Cojnel's analysis is correct, but it should be added that these messages will only be printed if the bounding box changes when moving one of the nodes

[Diederik van Lierop (mail-diedenrezi)]

I've talked to Krzysztof about this, and he believes the fix is OK too. The other stuff I mentioned is quite complex, and Krzysztof didn't have a quick solution either.. Anyway, it isn't really a bug, so I'll mark the this as "fix commited".