These were removed with crrev.com/1239193002, but a few were missed
in files that are only build on Android framework.
Brings the Android build one step closer to building.
Review URL: https://codereview.chromium.org/1268603003
Renames Sk4pxXfermode.h to SkXfermode_opts.h,
and refactors it a tiny bit internally.
This moves xfermode optimization from being "compile-time everywhere but NEON"
to simply "runtime everywhere". I don't anticipate any effect on perf or
correctness.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1264543006
With this new arrangement, the benefits of inlining sk_memset16/32 have changed.
On x86, they're not significantly different, except for small N<=10 where the inlined code is significantly slower.
On ARMv7 with NEON, our custom code is still significantly faster for N>10 (up to 2x faster). For small N<=10 inlining is still significantly faster.
On ARMv7 without NEON, our custom code is still ridiculously faster (up to 10x) than inlining for N>10, though for small N<=10 inlining is still a little faster.
We were not using the NEON memset16 and memset32 procs on ARMv8. At first blush, that seems to be an oversight, but if so it's an extremely lucky one. The ARMv8 code generation for our memset16/32 procs is total garbage, leaving those methods ~8x slower than just inlining the memset, using the compiler's autovectorization.
So, no need to inline any more on x86, and still inline for N<=10 on ARMv7. Always inline for ARMv8.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1270573002
The decoding tests can now veto indirect sinks like pipe-8888.
This moves Sink type detection from automatic to explicit; I can't think of any
way to automatically differentiate pipe-8888 from 8888 based only on the
output. (They should ideally be identical, after all.)
BUG=skia:4138
Review URL: https://codereview.chromium.org/1263113002
Currently the SampleApp and VisualBench builds for Android don't work
for rebuilds. The code is re-built, but the apks are not. This
results from the use of a directory as 'output' and the action to
build the apk not depending on the copied libraries.
Review URL: https://codereview.chromium.org/1270643005
Use EXT_blend_func_extended to implement dual source blending in OpenGL
ES. The extension is the ES version of ARB_blend_func_extended.
The extension provides gl_SecondaryFragColorEXT for ES 2.0 contexts.
The extension provides glBindFragDataLocationIndexed to bind a custom
fragment shader output to the secondary color for ES 3.0 contexts.
For ES 3.1 contexts, the extension would also give
"layout (location=0, index=1)" output varible layout modifier syntax,
but it is not used in this patch.
The extension needs #extension GL_EXT_blend_func_extended : require
directive for the variables to be available in ES 2.0. For ES 3.0, the
directive relaxes the rules for the amount of output variables without
layout location qualifiers.
OpenGL continues to use GL_ARB_blend_func_extended for dual source
blending.
Review URL: https://codereview.chromium.org/1266773003
Make it possible to turn MSAA on and off for OpenGL ES, too.
Use EXT_multisample_compatibility.
The extension adds token:
MULTISAMPLE_EXT 0x809D
The token can be supplied to glEnable/glDisable/glGetInteger.
This is needed in order to support mixed samples in OpenGL ES. This is
important for path rendering Chromium command buffer integration.
Review URL: https://codereview.chromium.org/1270533002
In CodecSrc's scanline_subset test, we decode a subset of an image to a
bitmap, draw it to the canvas, and then repeat. This is fine for most
backends, but not for pipe. Pipe sees the same generation ID, so it
assumes it is the same bitmap it saw before, and just draws the
original one.
Call notifyPixelsChanged, so the bitmap will get a new generation ID,
fixing pipe.
BUG=skia:4138
Review URL: https://codereview.chromium.org/1265983004
This enables the NEON sk_float_rsqrt() code for configurations that have NEON at run-time but not compile-time.
These devices will see about a 2x (1.26 -> 2.33) slowdown in sk_float_rsqrt(), but it should be more precise than our portable fallback.
(When inlined, the portable fallback and the NEON code are almost identical in speed. The only difference is precision. Going through a function pointer is causing all this slowdown. This is a good example of a place where Skia really benefits from compile-time NEON.)
BUG=skia:4117,skia:4114
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1264893002
