2015-03-25 20:43:34 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright 2015 Google Inc.
|
|
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
|
* found in the LICENSE file.
|
|
|
|
|
*/
|
|
|
|
|
|
2015-02-23 18:04:34 +00:00
|
|
|
#include "SkPMFloat.h"
|
|
|
|
|
#include "Test.h"
|
|
|
|
|
|
|
|
|
|
DEF_TEST(SkPMFloat, r) {
|
2015-02-26 18:43:16 +00:00
|
|
|
// Test SkPMColor <-> SkPMFloat
|
2015-02-23 18:04:34 +00:00
|
|
|
SkPMColor c = SkPreMultiplyColor(0xFFCC9933);
|
2015-03-04 19:25:27 +00:00
|
|
|
SkPMFloat pmf(c);
|
Convert SkPMFloat to [0,1] range and prune its API.
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
2015-06-25 15:56:28 +00:00
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(255.0f, 255*pmf.a()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(204.0f, 255*pmf.r()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(153.0f, 255*pmf.g()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual( 51.0f, 255*pmf.b()));
|
2015-04-03 14:05:20 +00:00
|
|
|
REPORTER_ASSERT(r, c == pmf.round());
|
2015-02-23 18:04:34 +00:00
|
|
|
|
2015-03-23 19:01:45 +00:00
|
|
|
// Test rounding.
|
Convert SkPMFloat to [0,1] range and prune its API.
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
2015-06-25 15:56:28 +00:00
|
|
|
pmf = SkPMFloat(254.5f/255, 203.5f/255, 153.1f/255, 50.8f/255);
|
2015-04-03 14:05:20 +00:00
|
|
|
REPORTER_ASSERT(r, c == pmf.round());
|
2015-02-23 18:04:34 +00:00
|
|
|
|
Convert SkPMFloat to [0,1] range and prune its API.
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
2015-06-25 15:56:28 +00:00
|
|
|
SkPMFloat clamped(SkPMFloat(510.0f/255, 153.0f/255, 1.0f/255, -0.2f/255).round());
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(255.0f, 255*clamped.a()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(153.0f, 255*clamped.r()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual( 1.0f, 255*clamped.g()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual( 0.0f, 255*clamped.b()));
|
2015-02-26 18:43:16 +00:00
|
|
|
|
2015-03-31 15:17:00 +00:00
|
|
|
// Test SkPMFloat <-> Sk4f conversion.
|
|
|
|
|
Sk4f fs = clamped;
|
|
|
|
|
SkPMFloat scaled = fs * Sk4f(0.25f);
|
Convert SkPMFloat to [0,1] range and prune its API.
Now that Sk4px exists, there's a lot less sense in eeking out every
cycle of speed from SkPMFloat: if we need to go _really_ fast, we
should use Sk4px. SkPMFloat's going to be used for things that are
already slow: large-range intermediates, divides, sqrts, etc.
A [0,1] range is easier to work with, and can even be faster if we
eliminate enough *255 and *1/255 steps. This is particularly true
on ARM, where NEON can do the *255 and /255 steps for us while
converting float<->int.
We have lots of experimental SkPMFloat <-> SkPMColor APIs that
I'm now removing. Of the existing APIs, roundClamp() is the sanest,
so I've kept only that, now called round(). The 4-at-a-time APIs
never panned out, so they're gone.
There will be small diffs on:
colormatrix coloremoji colorfilterimagefilter fadefilter imagefilters_xfermodes imagefilterscropexpand imagefiltersgraph tileimagefilter
BUG=skia:
Review URL: https://codereview.chromium.org/1201343004
2015-06-25 15:56:28 +00:00
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(63.75f, 255*scaled.a()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual(38.25f, 255*scaled.r()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual( 0.25f, 255*scaled.g()));
|
|
|
|
|
REPORTER_ASSERT(r, SkScalarNearlyEqual( 0.00f, 255*scaled.b()));
|
2015-02-23 18:04:34 +00:00
|
|
|
}
|
