Repository navigation
Use fuzzy comparison for stroke join determination. - #10077
Conversation
| vc.remove_all(); | ||
|
|
||
| double cp = cross_product(v0.x, v0.y, v1.x, v1.y, v2.x, v2.y); | ||
| if(cp != 0 && (cp > 0) == (m_width > 0)) |
There was a problem hiding this comment.
What is the operator prescience in c++? Would
if(cp != 0 && ((cp > 0) == (m_width > 0)))also work?
There was a problem hiding this comment.
cp is non-zero on the other arches; it doesn't really have to do with precedence. The switch to two separate comparisons is so that -eps < cp < eps is considered 0.
|
There's another call to |
|
Unfortunately, it looks like Windows is producing |
4720fb3 to
4aaf1ef
Compare
4aaf1ef to
6c5f213
Compare
This sometimes produces something just slightly different from 0 compared to x86(_64).
The problem arises in some other location that is more difficult to determine than the previous one.
6c5f213 to
7216b8c
Compare
QuLogic
added
the
Release critical
|
Would like this in so we don't need too many downstream patches. |
| double cp = cross_product(v0.x, v0.y, v1.x, v1.y, v2.x, v2.y); | ||
| if(cp != 0 && (cp > 0) == (m_width > 0)) | ||
| if ((cp > agg::vertex_dist_epsilon && m_width > 0) || | ||
| (cp < -agg::vertex_dist_epsilon && m_width < 0)) |
There was a problem hiding this comment.
Not claiming to understand what you are doing here....
There was a problem hiding this comment.
Simply treating -eps < 0 < eps as 0 instead of strictly 0.
efiring
left a comment
efiring
left a comment
There was a problem hiding this comment.
Seems logical and worth a try, though I'm puzzled that apparently it required raising the tolerance on Windows.
|
Yea, I'm not happy about raising the tolerance for Windows either. Maybe I should try an increased epsilon instead? Edit: that just causes more failures on x86_64 Linux, so maybe not. |
![MeeseeksDev[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
The test image was re-generated and the tolerance removed in #10077. Re-store the tolerance on 2.1.x to gets tests passing, this should not be merged into master branch.
Backport PR #10077 on branch v2.1.x
PR Summary
This sometimes produces something just slightly different from 0 compared to x86(_64). I don't really know how to write a test for this as it only seems to be triggered on alternate arches, but a few test images got 'corrected', so I guess that's good enough.
Fixes #7797.
PR Checklist