SkRasterPipeline: new APIs for fusion
authormtklein <mtklein@chromium.org>
Fri, 29 Jul 2016 21:27:41 +0000 (14:27 -0700)
committerCommit bot <commit-bot@chromium.org>
Fri, 29 Jul 2016 21:27:41 +0000 (14:27 -0700)
commitfe2042e60fa7382461a45b1de0a02d345009f468
treecdb4eaf53c3f5d5979f5d4dbb5a74e90bec8ea5f
parent79b59e6a3877068067395ff8bd711c5332eb22a9
SkRasterPipeline: new APIs for fusion

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
bench/SkRasterPipelineBench.cpp
src/core/SkRasterPipeline.h
src/core/SkRasterPipelineBlitter.cpp
tests/SkRasterPipelineTest.cpp