Decompose splines with t flexibly updated

[weihsinyeh]

The evaluation testbed is font-edit, where I modified the implementation to use fixed-point arithmetic.

The font generated by the original implementation is as follows:

The font generated by the implementation of decomposing splines with flexibly updated t is as follows:

[jserv]

Replace "See also: #2" with "Close #2" in the git commit message, so that this issue can be closed automatically once this pull request is merged.
See https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue

[jouae]

Although this approach requires more computation to decompose the
spline into fewer segments, the extra effort is justified for improved
fit.

You can include statistical data such as mean, standard deviation, etc., in the PR and present it simply in the commit. Remember to mention the number of observations used.

[jouae]

• Left side one is the origin and right side one is your method
  

I merged two GIFs and slowed down the switching speed so that more people can clearly see your contributions.

[weihsinyeh]

original - Average number of _de_casteljau calls per point: 1.99
original - Average points per character: 18.89
flexibly update - Average number of _de_casteljau calls per point: 4.53
flexibly update - Average points per character: 16.30

[jserv]

Refine the git commit messages upon your experiments.

[jserv]

FYI: vector-graphics/src/bezier.h is an interesting implementation.

[jserv]

Google's skia performs subdivision using de Casteljau's algorithm, that is, repeated linear interpolation between adjacent points. See src/base/SkBezierCurves.cpp.

[weihsinyeh]

The following is the graph to illustrate the first time of calling the function De Casteljau's is redundant calculation.

I observed that when we apply shift 0.25 in the flexible setting, it will increase the average points per character. This indicates that when we limit the scope of 't' to [0, 0.25], we will fail to find some optimal point that has maximum curvature in the scope of 't' to [0.25, 0.5]. To verify it, we limit the scope of 't' to just [0,0.25]. The experiment is as follows:

Original (shift2) - Average number of _de_casteljau calls per point: 1.51
Original (shift2) - Average points per character: 18.98
Original (shift2) (limit scope) - Average number of _de_casteljau calls per point: 1.18
Original (shift2) (limit scope) - Average points per character: 22.57

Therefore, limiting the scope can decrease the average number of function '_de_casteljau' calls per point and increase the number of points. This means that these points do not always have the maximum curvature. In other words, some optimal point is located when the scope of t is [0.25, 1]. Therefore, in this pull request, we can dynamically increase the shift value without limitting the scope.

[weihsinyeh]

Another Idea:
There may be a new approach to rendering Bézier curves. Instead of calculating the points 'AB' 'BC' 'ABBC' in the left segment, which are colored red, we could calculate positions 'D' 'CD' 'BCCD' using only the right segment, which are colored blue.

This is because after rendering this turn, we only use the outcome of the right (blue) of the original spline to render an unhandled segment of spline. The left of the original spline (red) is dropped. What's even worse, not only the left of the original spline will be dropped, but also the intermediate results will be dropped (black font).

[weihsinyeh]

Assess the appropriate values for tolerance when rendering B´ezier Curve.

The following images show the effect of four settings on 56 fonts, which are rendered using curves. Only these fonts are used to calculate the average number of _de_casteljau calls per point and the average points per character.

Original (tolerance 0.0625) :

Original (tolerance 0.25) :

Original (shift2) :

Original (shift2) (tolerance 0.25) :

[weihsinyeh]

We perform multiple iterations each time we render a spline. In each iteration, there are multiple _de_casteljau function calls, which aim to find the most suitable shift value. The y-axis represents the number of shift attempts within one iteration. The x-axis represents the iterations of one spline. Since each spline has a different number of iterations, the iteration count is normalized to the range (0, 1). This allows us to observe the variation in the number of shift attempts at different stages of the iterations during the process of rendering a spline.

From the distribution above, we can see that in the original method, it takes an average of more than two shifts to find the optimal value during the first 60% of the spline rendering. It is also evident that as the rendering of a spline process reaches the later stages, the number of shifts gradually decreases. Therefore, based on the first finding, we set the initial shift to 2. Additionally, due to its gradually decreasing nature, the shifts used in different iterations of each spline will be stored as a global variable to record the value of the last shift change. This way, in the next iteration, we can directly use this value instead of starting from a shift of 2 again.

[jserv]

Squash the git commits. A single and informative one is preferable.

[weihsinyeh]

Assess the appropriate values for tolerance when rendering B´ezier Curve.

Should I evaluate it based on my own level of acceptance of the characters under different tolerances?

[jserv]

Add comments.

[jserv]

Thank @weihsinyeh for the great work!