Add epsilon API

[ctrlcctrlv]

Didn't think there was much point in fixing the epsila until the API is even approved. (See #178.)

[ctrlcctrlv]

note: i can remove these and make the functions non-const but someone here may have better idea

[raphlinus]

We discussed this in office hours today. Generally, seeing this and the back-and-forth in #178, I'm inclined to take this as confirmation that just making everything f64 is the right way to go. Making kurbo generic over precision is not a simple task, and in particular some of the algorithms have very careful numerical robustness work that has to be re-thought. In particular, the work in #230 relies on quartic solving which is very delicate with respect to precision. Making that numerically robust is likely possible (though I'm not sure of that), but would probably be a major effort.

There are use cases where f32 would be very desirable. The biggest is of course if it's running on a GPU (rust-gpu is on my radar). Another is if we're starting to do serious SIMD optimization. However, the costs are nontrivial.

I'd like to understand better exactly what the end goals are. Some goals are probably best met by having all the core algorithms run in f64 but perhaps having conversions to f32 at the edges (this is more or less what we do for Vello scene encoding). Other goals may be met by having, say, an f32 variant of BezPath that implements the Shape trait (we considered this for Vello encoding but ultimately decided against).

Regarding epsilons, we've had discussion on this point before. There's no "one size fits all" approach, and the choice of epsilon depends on the use case. For interactive applications, it's probably best to use the largest value that doesn't cause visual problems, to get the fastest performance. For other applications, it's important to get the right answer. The choice of epsilon can also depend on the range of scaling transforms that are expected and the coordinate system for the final result. Thus, we try not to use "magic constant" epsilon values, and instead pass in an accuracy parameter. It's appropriate to use concrete values in tests (and in general those should be small), as the goal is to detect anything that might cause loss of precision.

Long story short, I am against making a 32 bit version of kurbo unless I see a clear motivation, and until then I am inclined not to accept any changes to facilitate this.

[ctrlcctrlv]

There are use cases where f32 would be very desirable. The biggest is of course if it's running on a GPU (rust-gpu is on my radar). Another is if we're starting to do serious SIMD optimization. However, the costs are nontrivial.

My code does run on GPU as Skia uses the GPU.

[ctrlcctrlv]

Thus, we try not to use "magic constant" epsilon values, and instead pass in an accuracy parameter. It's appropriate to use concrete values in tests (and in general those should be small), as the goal is to detect anything that might cause loss of precision.

Primarily that's what this API is for, the tests, as that's where most (all?) of the epsila in the codebase are defined.

[raphlinus]

My code does run on GPU as Skia uses the GPU.

I specifically meant running in shaders or CUDA.