Hi Juce Team,
I believe I found a bug in a low level Juce routine in the PathStrokeHelpers namespace. On current tip in the file juce_PathStrokeType.cpp starting on line 152 you have:
const float along1 = ((y1 - y3) * dx2 - (x1 - x3) * dy2) / divisor;
intersectionX = x1 + along1 * dx1;
intersectionY = y1 + along1 * dy1;
if (along1 >= 0 && along1 <= 1.0f)
{
const float along2 = ((y1 - y3) * dx1 - (x1 - x3) * dy1);
if (along2 >= 0 && along2 <= divisor)
{
distanceBeyondLine1EndSquared = 0.0f;
return true;
}
}
This code incorrectly does not return true if the line does intersect, but divisor is below zero. I understand the optimization here was made to avoid the division, but the sign should still be taken into account IMHO. My fix was to just divide and test against the 0...1 range like it's done for along1.
I think it doesn't make a visible difference in path rendering currently, but I do think it eats some performance by treating regular cases as irregular cases when Paths are converted to Strokes..
I came across the problem when I needed to expand a Path by an offset. I couldn't find a way to do this with Juce, but realized Stroking a path almost does the same thing. So I took the Juce code and modified it for my purposes. Is there maybe already another way to expand a path in Juce?