stifle warning in tValue2Scalar()

Spun off from https://skia-review.googlesource.com/c/skia/+/242776.

I was worried there that this indicated a bug, that we're actually
working with a slightly-wrong denominator, but thanks to the wonders of
float rounding, turns out everything's probably ok.  This is the same as
that CL above with unit tests that the important boundary conditions
work correctly.

Change-Id: I1df469daf48df12f0e72778e6af58f5e733452ed
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/242841
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
This commit is contained in:
Mike Klein 2019-09-19 10:33:36 -05:00 committed by Skia Commit-Bot
parent b2f55532bb
commit 72d2f571ff

View File

@ -13,12 +13,16 @@
#define kMaxTValue 0x3FFFFFFF
static inline SkScalar tValue2Scalar(int t) {
constexpr static inline SkScalar tValue2Scalar(int t) {
SkASSERT((unsigned)t <= kMaxTValue);
const SkScalar kMaxTReciprocal = 1.0f / kMaxTValue;
// 1/kMaxTValue can't be represented as a float, but it's close and the limits work fine.
const SkScalar kMaxTReciprocal = 1.0f / (SkScalar)kMaxTValue;
return t * kMaxTReciprocal;
}
static_assert(0.0f == tValue2Scalar( 0), "Lower limit should be exact.");
static_assert(1.0f == tValue2Scalar(kMaxTValue), "Upper limit should be exact.");
SkScalar SkContourMeasure::Segment::getScalarT() const {
return tValue2Scalar(fTValue);
}