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
- Once in SkXfermode as usual to pick up compile-time SSE and NEON
- Once in SkXfermode_arm_neon to pick up run-time NEON
This allows us to start cleaning up SkXfermode_arm_neon as we've done
for SkXfermode_SSE2. I'm saving this catharsis for a day when I need it.
The Sk4px xfermodes are generally faster than the existing NEON procs,
so this should also have the side effect of a perf win there.
This means our new Plus-AA code works for runtime NEON too.
BUG=skia:3852
Review URL: https://codereview.chromium.org/1150313003
GrContext draw functions (drawRect, drawRRect,...) fall back to
GrContext::drawPath for complex cases. Mark the argument SkPath
as volatile, since it is.
Progressions for nvprmsaa:
tabl_androidpolice.skp_1 11.6ms -> 10.3ms 0.89x
desk_twitter.skp_1 9.21ms -> 8.08ms 0.88x
tabl_sahadan.skp_1 8.97ms -> 7.65ms 0.85x
desk_wikipedia.skp_1 5.63ms -> 4.5ms 0.8x
desk_booking.skp_1 11.5ms -> 8.87ms 0.77x
desk_ebay.skp_1 7ms -> 5.37ms 0.77x
Makes rrects and rects go to "simple path" path cache (cached by contents).
No change for msaa, gpu.
BUG=skia:
Review URL: https://codereview.chromium.org/1150993002
Two major things have happened:
1. Android bots split between more machines. This caused lots of
congestion-related failures, leading to...
2. All buildslaves now use a single checkout for all of the builders
that they run. This should give us far fewer problems when we have
to re-download SKPs, toolchains, etc.
TBR=rmistry
BUG=skia:3835,3774
Review URL: https://codereview.chromium.org/1154603002
Moves the cap for mixed samples into GrShaderCaps and does not enable
it unless we have support for both dual source blending and
multisample disable.
Creates a dedicated cap for multisample disable.
Reconfigures the mixed samples cap to indicate the collective
capability of three different extensions:
GL_NV_framebuffer_mixed_samples
GL_NV_sample_mask_override_coverage
GL_EXT_raster_multisample
Imports tokens and procedures for GL_EXT_raster_multisample.
BUG=skia:
Review URL: https://codereview.chromium.org/1151793002
Constructing the gm tests and benches causes many calls to font loads.
This is visible as profiling samples in fontconfig and freetype on Linux
for all profiling runs of nanobench. This complicates analysis of
test-cases that are suspected of being slow due to font-related issues.
Move the font loading to GM::onOnceBeforeDraw and Benchmark::onPreDraw.
This way the code is not executed if the testcase does not match the
nanobench --match filter. This way the samples in font-related code are
more easy to identify as legitimate occurances caused by the testcase.
This should not cause differences in timings, because:
* Benchmark::preDraw / onPreDraw is defined to be run outside the timer
* GM::runAsBench is not enabled for any of the modified testcases. Also
nanobench untimed warmup round should run the onOnceBeforeDraw.
(and there are other GM::runAsBench gms already doing loading in
onOnceBeforeDraw).
Changes the behavior:
In TextBench:
Before, the test would report two different gms with the same name if
the color emoji font was not loaded successfully.
After, the test always reports all tests as individual names.
Generally:
The errors from loading fonts now print inbetween each testcase, as
opposed to printing during construction phase. Sample output:
( 143/145 MB 1872) 14.7ms 8888 gm quadclosepathResource /fonts/Funkster.ttf not a valid font.
( 160/160 MB 1831) 575µs 8888 gm surfacenewResource /fonts/Funkster.ttf not a valid font.
( 163/165 MB 1816) 12.5ms 8888 gm linepathResource /fonts/Funkster.ttf not a valid font.
( 263/411 MB 1493) 118ms 8888 gm typefacestyles_kerningResource /fonts/Funkster.ttf not a valid font.
( 374/411 MB 1231) 7.16ms 565 gm getpostextpathResource /fonts/Funkster.ttf not a valid font.
( 323/411 MB 1179) 4.92ms 565 gm stringartResource /fonts/Funkster.ttf not a valid font.
( 347/493 MB 917) 191ms 565 gm patch_gridResource /fonts/Funkster.ttf not a valid font.
( 375/493 MB 857) 23.9ms gpu gm clipdrawdrawCannot render path (0)
( 393/493 MB 706) 2.91ms unit test ParsePath------ png error IEND: CRC error
( 394/493 MB 584) 166ms gpu gm hairmodesResource /fonts/Funkster.ttf not a valid font.
Resource /fonts/Funkster.ttf not a valid font.
Resource /fonts/Funkster.ttf not a valid font.
...
Review URL: https://codereview.chromium.org/1144023002
Specifying vertex attributes and the view matrix as mediump causes bad artifacts on Mali T6XX.
Covered by the bigmatrix GM in msaa4 mode.
BUG:skia=3545,3771
Review URL: https://codereview.chromium.org/1145273002
This requires we "first" add a has-picture bool to SkPictureShader serialized format.
BUG=chromium:486947, billions and billions of others.
Review URL: https://codereview.chromium.org/1151663002
This re-enables adoption tracking for SkPictures in Blink,
which should be green now that crrev.com/1136123011 has landed.
BUG=skia:3847
Review URL: https://codereview.chromium.org/1145153002
In my confusion yesterday I accidentally left this as a non-singleton.
The issue in Blink was not related to this being a singleton,
and it should be safe to make it one.
This means recording an empty picture properly costs zero mallocs.
BUG=skia:
Review URL: https://codereview.chromium.org/1147053002
Prior to the introduction of find.py, GMs were liked in the order they
were listed in the gypi file, which was generally alphabetically. This
made it fairly easy to predict where slides would show up in SampleApp
and the order was consistent. This simply sorts the list of files in
find.py to restore the expectation that files should be listed in the
build in alphabetical order.
Review URL: https://codereview.chromium.org/1144973003
If one of the inputs to a SkMergeImageFilter was clipped away or
otherwise caused the filterImage(...) invocation for it to return
false, the entire effect would be "failed" and return false --
regardless of if it had produced a result or not.
Instead of returning false directly if filterImage(...) for a source
returned false, consider all the inputs, and then only return false if
all of them do.
BUG=chromium:489046
Review URL: https://codereview.chromium.org/1133523006
