Simplify CalcNumRadialSegmentsPerRadian signature
The conceptual meat of this change is that instead of taking a local-to-
device scale factor and the local stroke width, CalcNumRadialSegments
now takes the approximated device-space stroke radius. The main benefit
of this is that hairlines can be defined exactly without needing to
invert the local-to-device matrix or otherwise estimate a local-space
radius that would transform to the 1px hairline. The actual math for
regular strokes remains the same (scale factor * radius), but is moved.
In addition, this CL fixes a bug I had introduced in
https://skia-review.googlesource.com/c/skia/+/502059/
where I had not realized the CPU code operated on stroke *width* and the
GPU code operated on stroke *radius*, so updating them to use the same
equations w/o changing their inputs actually caused us to overestimate
the number of radial segments required. With this change, both the CPU
code and GPU code operate on stroke radius.
Between that bug fix and simplifying the hairline stroke radius math,
I am expecting lots of slight AA changes around stroked paths.
Lastly, I entirely removed the StrokeTolerancesBuffer, which was a class
that buffered up calculations of CalcNumRadialSegments by looking at the
entire list of paths in an op and putting them into a 4-lane SIMD
function instead. This isn't currently available for Graphite and makes
it harder to consolidate the radial segment calculations. Locally I
found no noticeable difference in the patch writing microbenchmarks
(where it would be more significant), and somehow the motionmark SKPs
were actually a touch faster. I'm hopeful that we can drop this
complexity and not take a large performance hit.
Bug: skia:13056, skia:13012
Change-Id: If16103078ebe9e4e60470445c0868deb3904f7de
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/537239
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
6 files changed