fe2042e60f
Most visibly this adds a macro SK_RASTER_STAGE that cuts down on the boilerplate of defining a raster pipeline stage function. Most interestingly, SK_RASTER_STAGE doesn't define a SkRasterPipeline::Fn, but rather a new type EasyFn. This function is always static and inlined, and the details of interacting with the SkRasterPipeline::Stage are taken care of for you: ctx is just passed as a void*, and st->next() is always called. All EasyFns have to do is take care of the meat of the work: update r,g,b, etc. and read and write from their context. The really neat new feature here is that you can either add EasyFns to a pipeline with the new append() functions, _or_ call them directly yourself. This lets you use the same set of pieces to build either a pipelined version of the function or a custom, fused version. The bench shows this off. On my desktop, the pipeline version of the bench takes about 25% more time to run than the fused one. The old approach to creating stages still works fine. I haven't updated SkXfermode.cpp or SkArithmeticMode.cpp because they seemed just as clear using Fn directly as they would have using EasyFn. If this looks okay to you I will rework the comments in SkRasterPipeline to explain SK_RASTER_STAGE and EasyFn a bit as I've done here in the CL description. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2195853002 Review-Url: https://codereview.chromium.org/2195853002
87 lines
2.2 KiB
C++
87 lines
2.2 KiB
C++
/*
|
|
* Copyright 2016 Google Inc.
|
|
*
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
* found in the LICENSE file.
|
|
*/
|
|
|
|
#include "Test.h"
|
|
#include "SkRasterPipeline.h"
|
|
|
|
// load needs two variants, one to load 4 values...
|
|
SK_RASTER_STAGE(load) {
|
|
auto ptr = (const float*)ctx + x;
|
|
r = Sk4f{ptr[0]};
|
|
g = Sk4f{ptr[1]};
|
|
b = Sk4f{ptr[2]};
|
|
a = Sk4f{ptr[3]};
|
|
}
|
|
|
|
// ...and one to load a single value.
|
|
SK_RASTER_STAGE(load_tail) {
|
|
auto ptr = (const float*)ctx + x;
|
|
r = Sk4f{*ptr};
|
|
}
|
|
|
|
// square doesn't really care how many of its inputs are active, nor does it need a context.
|
|
SK_RASTER_STAGE(square) {
|
|
r *= r;
|
|
g *= g;
|
|
b *= b;
|
|
a *= a;
|
|
}
|
|
|
|
// Like load, store has a _tail variant.
|
|
SK_RASTER_STAGE(store) {
|
|
auto ptr = (float*)ctx + x;
|
|
ptr[0] = r[0];
|
|
ptr[1] = g[0];
|
|
ptr[2] = b[0];
|
|
ptr[3] = a[0];
|
|
}
|
|
|
|
SK_RASTER_STAGE(store_tail) {
|
|
auto ptr = (float*)ctx + x;
|
|
*ptr = r[0];
|
|
}
|
|
|
|
DEF_TEST(SkRasterPipeline, r) {
|
|
// We'll build up and run a simple pipeline that exercises the salient
|
|
// mechanics of SkRasterPipeline:
|
|
// - context pointers
|
|
// - stages sensitive to the number of pixels
|
|
// - stages insensitive to the number of pixels
|
|
//
|
|
// This pipeline loads up some values, squares them, then writes them back to memory.
|
|
|
|
const float src_vals[] = { 1,2,3,4,5 };
|
|
float dst_vals[] = { 0,0,0,0,0 };
|
|
|
|
SkRasterPipeline p;
|
|
p.append<load, load_tail>(src_vals);
|
|
p.append<square>();
|
|
p.append<store, store_tail>(dst_vals);
|
|
|
|
p.run(5);
|
|
|
|
REPORTER_ASSERT(r, dst_vals[0] == 1);
|
|
REPORTER_ASSERT(r, dst_vals[1] == 4);
|
|
REPORTER_ASSERT(r, dst_vals[2] == 9);
|
|
REPORTER_ASSERT(r, dst_vals[3] == 16);
|
|
REPORTER_ASSERT(r, dst_vals[4] == 25);
|
|
}
|
|
|
|
DEF_TEST(SkRasterPipeline_empty, r) {
|
|
// No asserts... just a test that this is safe to run.
|
|
SkRasterPipeline p;
|
|
p.run(20);
|
|
}
|
|
|
|
DEF_TEST(SkRasterPipeline_nonsense, r) {
|
|
// No asserts... just a test that this is safe to run and terminates.
|
|
// square() always calls st->next(); this makes sure we've always got something there to call.
|
|
SkRasterPipeline p;
|
|
p.append<square>();
|
|
p.run(20);
|
|
}
|