Unnecessary moves cause extra moves and longer moves, with no benefits

[kefir-]

I'm testing latest git head with the same files and config used in https://github.com/alexrj/Slic3r/issues/1907#issuecomment-41333388, and I've noticed that slic3r adds some seemingly completely unnecessary moves. They're not a big problem for this part, but I'm reporting this because the logic doesn't really make sense, and this might be a useful test case. I'll try to describe with some screenshots, and include the gcode.

This is the last island of this layer, and the perimeter is almost done. It is being drawn counter-clockwise:

This is how it looks when it's done, finishing in the lower right corner:

Here is the unnecessary move, for some reason the nozzle is moved from the lower right corner to the lower left corner. I don't see any good argument for doing this move:

Here the infill is started, moving clockwise from the lower left corner:

Here we can see what it looks like when the layer is done, excluding the final retract in the lower left corner. As you can see, the infill also overlaps itself a bit, looking a little like some of the artifacts seen in #1875:

This is the first move of the next layer. It may not be possible to see, but it is moving to the right. That means that the unnecessary move done above was doubly unnecessary, because it has added extra distance to this move as well. Interestingly, the optimal case seems to be just to drop the unecessary move every time.

The very first layer is special, but the next 19 layers seem to do this. Here's the gcode:

http://kefirshare.dreamhosters.com/bridge-torture-test_m2_20140429-230956_1.1.2-dev.gcode

[ledvinap]

The infill part is property of current implementation of medial-axis. It does not find loops correctly(or at all?), so it finds path from some entry point (selected by its relationship to surrounding polygon). The resulting path is most probably 'correct' result of math used ...

[alranel]

Yes, I think once the problem causing the extra tiny segments is fixed, that gap fill will be detected as a loop (there's already logic for that in _fill_gaps() and it will be started at the most convenient point instead at the entry point on the left.

[alranel]

Still, I love this linear gap fill. :)

[alranel]

@kefir-, I think 08279ec fixes this. Let me know when you have a chance! Thank you!

[kefir-]

As far as I can tell, the unnecessary moves still happen with my test part. The artifacts where the infill returns to the starting point seem to be gone, however, so that looks much better.

[alranel]

Thank you for testing @kefir-. I now fixed loop detection and I confirm that unnecessary moves are gone since the internal loop is started at the nearest point: