Well done, it looks very promising!

Today is electronics day, I have some projects to finish with atmega and other junk. I'll find a moment to try the new version of the algorithm.

I didn't' measure performance and I can't obtain some G2/G3 curve from the potrace output

All the filling is done via G1, even that the "Inset" mode.
Only the final border pass use G2/G3 and it is treated with the old function (that keeps the old name "OptimizePaths" while the new one is called "OptimizeFillingPaths")

From a quick test I believe that the problem, which I see, with the reversal of the paths, is still there.

I honestly do not really understand the cause, but if I use the code in master, where I have disabled the inversion, and that of this commit, here's what comes with the diagonal grid filling:

As you can see there is a lot of red (non tracing) moves, which are not in the master version.

Keep in mind that when I generate the vector grid (be it horizontal, vertical or diagonal) I take care a priori of reversing the direction between even and odd lines of generated segments, so it is in the natural order of things that near the end of a segment there is the start of a subsequent segment.

Probably using Diagonal Cross Fill was not a good choice for test.. actually I was already flipping the curve so messing with cases.

Only the final border pass use

I've try to use the OptimizeFillingPaths with the RAS sample, but still I can't reproduce the crazy G2/G3 behavior you show:

Only missing a sector in the inside of the A hole ( still to investigate)

I've try to use the OptimizeFillingPaths with the RAS sample, but still I can't reproduce the crazy G2/G3 behavior you show:
Only missing a sector in the inside of the A hole ( still to investigate)

Did you switch on "Smoothing" flag? I think that Potrace is not producing arcs without "smoothing" flag.

A final consideration: every time there is a change of direction, grbl has to decelerate the movement to zero speed, for obvious physical reasons, then it can restart in the new direction with an acceleration ramp up to the target speed.

In the real world this often causes that, the advantage given by looking for the nearest segment, compared to continuing in the same direction but with a further segment, is not as high. In fact, sometimes performance can even decrease.

Obviously this phenomenon is quite complex to take into account, largely depending on how fast or not the deceleration can be (machine configuration) as well as the "rapid movement" speed (other machine configuration) and the distance to travel on the rapid movement.

Seems like a typical Rabbit Hole 😄 , and probably a simply approach is better.
I dig the code to find out why the Curve was not reversed correctly. When smoothing Potrace genereate a list of curves that can be Linear or Beizer. They seems to be segments of Quadratic Bezier with start point A , end point B and relative controls points. If so it should be enought to swap the values, but the results are that crazy circles that jump out in the wrong quadrants.
The culprits could be the part of Potrace code that try to approximate the CubicBezier to BiArcs, but anyway the optimizations seems not so efficient as I was expecting.

Please check with your case if everything is producing valid results.

My fault, i forget that potrace gives bezier as output.

Well... I see that the last code you commit does not invert: in my opinion it is the best thing (and no problem with the bezier).

Please check with your case if everything is producing valid results.

Well, I've done some tests and it seems to me that everything is almost ok.
Some small problems about the starting point, I changed the code to make the starting point be the first segment.

I saw that there was a list inversion in the GCODE export function, and a list inversion in the optimize function. Maybe two inversions are useless ... better none, or just one inversion in the right place (assuming it serves).

Seems like a typical Rabbit Hole

I like digging in rabbit hole, so I try to put an optimization that can take into account the direction change.
It weigh the distance with the other segments with a factor that depends on the change of direction.

In any case it is not easy to calibrate this "weight" because a lot depends on the distance between the filling lines, which is tightened by increasing the resolution of the filling, while the distance between segments "on the same direction" is always the same and depends on how the image is made.

As already mentioned, the goodness of this optimization it also depends on acceleration and speed.

if you want to test the "direction change" weight the line of code is

var af = 1; // DirectionChange(a1, a2, b1, 50);

Hi @HomineLudens
What do you think with this issue with the new filling mode?

#1218 (comment)

Am I right with my assumptions in last post?

I think the mechanical considerations are plausible.
The rounding error caused by comulative step approximation instead sounds strange. After all the y steps will always be the same both in left and right position.
I'll try to test same code on my machine and see what happens.