diff options
| author |  mtklein <mtklein@chromium.org> | 2015-04-27 14:22:32 -0700 |
|---|---|---|
| committer |  Commit bot <commit-bot@chromium.org> | 2015-04-27 14:22:32 -0700 |
| commit | d7c014ff03d44d3ed7a6a2ddca59621a7e98f739 (patch) | |
| tree | 0739bd83543af31c22ef25e1b352cedb56a4ee77 /src/effects | |
| parent | 498856ebc6f22d7018071bd6696756d7cd077ab8 (diff) | |
Split rsqrt into rsqrt{0,1,2}, with increasing cost and precision on ARM
This is a logical no-op. Everything was using the equivalent of rsqrt1() before, and is now after.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/9de16283fdc8cc0d31a84f503578d0ecea4e8297
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm64-Debug-Android-Trybot
Review URL: https://codereview.chromium.org/1109913002
Diffstat (limited to 'src/effects')
| -rw-r--r-- | src/effects/gradients/SkRadialGradient.cpp | 5 |
1 files changed, 2 insertions, 3 deletions
diff --git a/src/effects/gradients/SkRadialGradient.cpp b/src/effects/gradients/SkRadialGradient.cpp index bf3c821f6b..80562dece8 100644 --- a/src/effects/gradients/SkRadialGradient.cpp +++ b/src/effects/gradients/SkRadialGradient.cpp @@ -377,10 +377,9 @@ void shadeSpan_radial_clamp(SkScalar sfx, SkScalar sdx, } } -// TODO: can we get away with 0th approximatino of inverse-sqrt (i.e. faster than rsqrt)? -// seems like ~10bits is more than enough for our use, since we want a byte-index static inline Sk4f fast_sqrt(const Sk4f& R) { - return R * R.rsqrt(); + // R * R.rsqrt0() is much faster, but it's non-monotonic, which isn't so pretty for gradients. + return R * R.rsqrt1(); } static inline Sk4f sum_squares(const Sk4f& a, const Sk4f& b) { |