| Cool to see others working on this problem. I hope more people do. Funnily I've seen a lot of programmers and math folks who express how truly, genuinely beautiful Beziers and the math behind them are. But I've never met an artist or graphic designer who didn't express some deep frustration at Bezier controls and how hard they are to work with. There are even games[0] which make a mockery out of how hard Bezier controls are to use, where the game is purely using the controls. Controls are just one side of the problem, in my view; the other side is that cubics are terrible for GPUs, they don't understand them - and I believe many of the best 2D graphics libraries today are not even fully GPU accelerated, e.g. Skia. There are folks working on compute shader-based approaches, where we try to shoe-horn this CPU-focused algorithm into GPUs and pray - but it still isn't really suitable. The controls suck for artists, and the math sucks for GPUs. This is only true of cubics, if you restrict yourself to quadratics (although that brings other challenges), both the control issue goes away (you can just click+drag the curve!) and the performance issue goes away (quadratics are triangles, GPUs love them) That's the summary of the talk[1] I gave at SYCL'22. In that talk, I didn't have time to present the downsides of my solution (which are real!) so if you watch it please keep that in mind - the talk is about the problem statement, not a solution. We are exploring a different solution today than what was presented in that talk. My overall point in there, though, is a solid one: vector graphics as they exist today suck for artists and GPUs alike. The only reason we stick with vector graphics in their current form is because of SVG & compatibility with existing tooling. But isn't it crazy? We have new bitmap image formats all the time, and so few vector graphics formats. In Mach engine[2] we're continuing to explore this space, end-to-end, from author tooling -> format -> rendering. I'm not claiming we have a perfect solution, we don't, but we're at least thinking about this problem. Kudos to the authors of this article for thinking about this space as well. [0] https://bezier.method.ac/ [1] https://www.youtube.com/watch?v=QTybQ-5MlrE [2] https://machengine.org |
Donald E. Knuth seems to think pretty highly of this decision:
“The quadratic has the great advantage that there's a real cheap way to render them. You can make hardware to draw a quadratic spline lickety-split. It's all Greek mathematics, the conic sections. You can describe a quadratic spline by a quadratic equation (x, y) so that the value of f(x, y) is positive on one side of the curve and negative on the other side. And then you can just follow along pixel by pixel, and when x changes by one and y changes by one, you can see which way to move to draw the curve in the optimal way. And the mathematics is really simple for a quadratic. The corresponding thing for a cubic is six times as complicated, and it has extra very strange effects in it because cubic curves can have cusps in them that are hidden. They can have places where the function will be plus on both sides of the cubic, instead of plus on one side and minus on the other.
“The algorithm that's like the quadratic one, but for cubics, turns out that you can be in something that looks like a very innocuous curve, but mathematically you're passing a singular point. That's sort of like a dividing by zero even though it doesn't look like there's any reason to do so. The bottom line is that the quadratic curves that TrueType uses allow extremely fast hardware implementations, in parallel.”
https://lists.nongnu.org/archive/html/freetype-devel/2000-01...