fix(#8344): stroke projection

[luizzappa]

Added tests for #8344

Tests revealed bugs and edge cases that this PR addresses.

The goldens make reading the diff impossible since github boils. View the diff here instead https://github.com/fabricjs/fabric.js/compare/8374-view-diff

[luizzappa]

The tests are generating around 3,000 images. It makes sense? Or is it better to define some sets of points beforehand, and just apply scale, skew and miterLimit?

[luizzappa]

It seems to me that the goldens were generated by node (which has a problem with miter-limit)

[ShaMan123]

If we can test all cases with very little tests that is the best

[luizzappa]

I reduced the amount of tests to be more targeted. I think it's better this way.

Goldens look like they are being generated by node instead of browser, due to miter-limit issue:

[luizzappa]

Tests reveal a bug when the strokeLineJoin is bevel or miter and has a straight angle

The problem seems to me is that in these cases we only project "outwards", this works for almost all points arrangements, but in the straight angle a straight line is formed, so we need projections to both sides.

If we check if the bisector angle is equal to PI, and in those cases project to both sides, we fix that. (not tested yet)

[ShaMan123]

If we check if the bisector angle is equal to PI, and in those cases project to both sides, we fix that. (not tested yet)

Maybe we use line cap projections in the case?

[ShaMan123]

Goldens look like they are being generated by node instead of browser, due to miter-limit issue:

What cmd are you using?

[ShaMan123]

make sure you run with -- -c chrome

Resize the goldens. White space is very bad since it is counted as pixels, making the diff% inaccurate.

[ShaMan123]

I see that is stroke line cap tests the stroke line join is wrong, I am correct?
Does it come from a bug in tests?

[ShaMan123]

@asturur this is waiting too long

[ShaMan123]

Dear @luizzappa !
I hope I find you in a good and happy state.
My apologies for not seeing this PR through.
It is very good work and a shame it has been stale for so long.
I have done my best to fast forward it to the current master but I might have done something wrong. I suspect so. But I doubled checked with a view diffs (8374-view-diff...8374-polyline-diff) to make sure but still, your review is priceless.
Once you give a green light I merge it straight away.

[ShaMan123]

I approved, if you have rights to squash and merge you are welcome to do so.

[asturur]

@luizzappa thanks for bringing this forward.
The reason why was waiting so long is because i m trying to finish the TS transition of the library and write documentation.
I would eventually not merge anything till that is done but @ShaMan123 can't really resist.

The issue with merging things is that we add new things to the library that later with a revise of documentation could entirely stop to make sense and then we would be in the weird position to make changes to code just merged.

I really would love to not add more code while we are in this beta status for so long.

[ShaMan123]

It is a bug fix I need
As many of my PRs, these are things I need

[ShaMan123]

I brought it up from the dead

[ShaMan123]

I sort of accept the fact that my prs wait until they are stale, not happy about it.
But I do not think it supports people contributing to the project, the opposite actually

[asturur]

I know i m not happy everything to be stale either.
I accepted TS and Classes as a way to improve the library, even if i don't fully believe in them, and i m committed to finish it now. As i said 1000 times, adding more stuff while doing it is counter poductive.