I ran into an issue building and testing this package with compiler architecture set for Skylake CPUs. This allows Skia to exploit vector processing capabilities which have a higher throughput and performance-per-watt but lower precision.
Some prior work 39dd41cab82314f9e7aab01a7a2bdf77bb89ae17 addressed the issue but introduces a numeric bug. Firstly, the actual and expected coordinates are rounded to a given grid precision:
There are changes at the fourth decimal digit in a few values: 156.2706 vs 156.2707, 75.6604 vs 75.6605.
Rounding the values before comparison can cause values that are within a unit of rounding to end up at different values. For instance, 0.499 and 0.501 differ by 0.002 but rounded to the nearest integer by the usual conventions we end up with 0 and 1.
I ran into an issue building and testing this package with compiler architecture set for Skylake CPUs. This allows Skia to exploit vector processing capabilities which have a higher throughput and performance-per-watt but lower precision.
Some prior work 39dd41cab82314f9e7aab01a7a2bdf77bb89ae17 addressed the issue but introduces a numeric bug. Firstly, the actual and expected coordinates are rounded to a given grid precision:
https://github.com/fonttools/skia-pathops/blob/39dd41cab82314f9e7aab01a7a2bdf77bb89ae17/tests/pathops_test.py#L133-L134
These values are subsequently compared for exact equality:
https://github.com/fonttools/skia-pathops/blob/39dd41cab82314f9e7aab01a7a2bdf77bb89ae17/tests/pathops_test.py#L137
Here's an example of the failure from
PathTest.test_transform:There are changes at the fourth decimal digit in a few values:
156.2706vs156.2707,75.6604vs75.6605.Rounding the values before comparison can cause values that are within a unit of rounding to end up at different values. For instance, 0.499 and 0.501 differ by 0.002 but rounded to the nearest integer by the usual conventions we end up with 0 and 1.