Removes the runtime logic used by PorterDuffXferProcessor to decide
blend coeffs and shader outputs, and instead uses a compile-time
constant table of pre-selected blend formulas.
Introduces a new blend strategy for srcCoeff=0 that can apply coverage
with a reverse subtract blend equation instead of dual source
blending.
Adds new macros in GrBlend.h to analyze blend formulas both runtime.
Removes kSetCoverageDrawing_OptFlag and GrSimplifyBlend as they are no
longer used.
Adds a GM that verifies all xfermodes, including arithmetic, with the
color/coverage invariants used by Porter Duff.
Adds a unit test that verifies each Porter Duff formula with every
color/coverage invariant.
Major changes:
* Uses a reverse subtract blend equation for coverage when srcCoeff=0
(clear, dst-out [Sa=1], dst-in, modulate). Platforms that don't
support dual source blending no longer require a dst copy for
dst-in and modulate.
* Sets BlendInfo::fWriteColor to false when the blend does not modify
the dst. GrGLGpu will now use glColorMask instead of blending for
these modes (dst, dst-in [Sa=1], modulate ignored for [Sc=1]).
* Converts all SA blend coeffs to One for opaque inputs, and ISA to
Zero if there is also no coverage. (We keep ISA around when there
is coverage because we use it to tweak alpha for coverage.)
* Abandons solid white optimizations for the sake of simplicity
(screen was the only mode that previous had solid white opts).
Minor differences:
* Inconsequential differences in opt flags (e.g. we now return
kCanTweakAlphaForCoverage_OptFlag even when there is no coverage).
* Src coeffs when the shader outputs 0.
* IS2C vs IS2A when the secondary output is scalar.
BUG=skia:
Review URL: https://codereview.chromium.org/1124373002
Updates GrXferProcessor to read directly from the RT texture when
texture barriers are supported and it needs to know the dst color.
Also adds the notion of an Xfer barrier and uses it to issue texture
barriers when the XP will read the RT.
BUG=skia:
Review URL: https://codereview.chromium.org/1040303002
Effectively all this does is future-proof any GLSL-specific code, as
GLSLCaps is just a typedef of GLCaps.
BUG=skia:
Review URL: https://codereview.chromium.org/1109863004
Adds an onGetBlendInfo method for GrXferProcessor subclasses to
override instead of overriding getBlendInfo directly. This gives the
base class a chance to initialize the struct with default values
before passing it on. As the BlendInfo struct grows, this will keep
things simple and less error prone.
BUG=skia:
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1049143002
Since only XP's can read dst now, there is no reason to have this query on GrFP.
This also triggered a chain reaction of cleaning up/removing unnecessary code
elsewhere.
BUG=skia:
Review URL: https://codereview.chromium.org/851143003
The Invariant output holds information about final post blended color and other
general information like will it blend with dst. Having this new struct allowed
me to also remove some functions that were previously querying subsets of the
invariant output.
BUG=skia:
Review URL: https://codereview.chromium.org/814933002
This is needed since clearColorStages is being changed to ignore color input. For RGB coverage,
we want to clear all the color stages (since we know the final output color), but we don't want
to ignore the color input since it is needed.
In future we will change this so the XP stores the color internally and thus can tell the GP to
simiply ignore color.
BUG=skia:
Review URL: https://codereview.chromium.org/791933006
This includes:
-Having an actual XP stage at the end of the gl pipeline.
-All Blending work is handled by XP until actually setting GL blend states
-GLPrograms test to test XP
BUG=skia:
Review URL: https://codereview.chromium.org/764643004
Reason for revert:
break many gm's
Original issue's description:
> Make all blending up to GrOptDrawState be handled by the xp/xp factory.
>
> In this cl the blending information is extracted for the xp and stored in the ODS
> which is then used as it currently is. In the follow up cl, an XP backend will be added
> and at that point all blending work will take place inside XP's.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7c66342a399b529634bed0fabfaa562db2c0dbd4TBR=bsalomon@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/766653008
In this cl the blending information is extracted for the xp and stored in the ODS
which is then used as it currently is. In the follow up cl, an XP backend will be added
and at that point all blending work will take place inside XP's.
BUG=skia:
Review URL: https://codereview.chromium.org/759713002
