| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1257253005
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1242403005
|
|
|
|
|
|
| |
BUG=chromium:515966
Review URL: https://codereview.chromium.org/1268723005
|
|
|
|
|
|
|
|
| |
BUG=skia:4157
NOTRY=true
TBR=
Review URL: https://codereview.chromium.org/1267843002
|
|
|
|
|
|
|
|
| |
BUG=skia:4157
NOTRY=true
DOCS_PREVIEW= https://skia.org/user/api/skpaint?cl=1270643004
Review URL: https://codereview.chromium.org/1270643004
|
|
|
|
|
|
|
| |
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1261433006
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1259143006
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1263463003
|
|
|
|
|
|
|
|
| |
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/adcdca86ce425cf8c28bfad311cef028df756ee8
Review URL: https://codereview.chromium.org/1266003002
|
|
|
|
|
|
| |
R=robertphillips@google.com
Review URL: https://codereview.chromium.org/1268953002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:4152
Review URL: https://codereview.chromium.org/1259123003
|
|
|
|
|
|
| |
BUG=chromium:513797
Review URL: https://codereview.chromium.org/1265003002
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1262333006
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1253003005
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1271533002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#3 id:40001 of https://codereview.chromium.org/1266003002/)
Reason for revert:
breaking android
Original issue's description:
> Modifying TextBlobCacheTest to use SkRandomScalerContext
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/adcdca86ce425cf8c28bfad311cef028df756ee8
TBR=bungeman@google.com,bsalomon@google.com,joshualitt@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1267623004
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1266003002
|
|
|
|
|
|
| |
no longer require access to GrContext.
Review URL: https://codereview.chromium.org/1265763002
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1268893002
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=510931
Review URL: https://codereview.chromium.org/1268743002
|
|
|
|
|
|
|
|
| |
This CL:
switches the light colors to be 3 scalars (SkColor3f)
adds some dox
Review URL: https://codereview.chromium.org/1265983003
|
|
|
|
|
|
|
|
|
|
|
| |
Launches an app, pipes its output, and exits when the app exits.
Loosely based on the old buildbot code in python:
https://skia.googlesource.com/buildbot/+/ac0663c599a443a4958c8cad5aefd25eb09eff58/slave/skia_slave_scripts/utils/android_utils.py
BUG=skia:4093
Review URL: https://codereview.chromium.org/1256353002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1266143003
|
|
|
|
|
|
|
|
|
| |
fBitmap was not fully constructed yet
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1264773004
|
|
|
|
|
|
|
|
| |
I view this as a performance opportunity, not a feature or bug fix per-se.
BUG=skia:
Review URL: https://codereview.chromium.org/1266883002
|
|
|
|
|
|
|
| |
TBR=jvanverth@google.com
BUG=skia:4148
Review URL: https://codereview.chromium.org/1266933002
|
|
|
|
|
|
|
|
|
|
| |
Speculative fix for this bug:
BUG=chromium:515679
TBR=robertphillips@google.com
Review URL: https://codereview.chromium.org/1268493003
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1264003002
|
|
|
|
|
|
|
|
| |
initialized before we start using the maskformat.
BUG=skia:
Review URL: https://codereview.chromium.org/1270573003
|
|
|
|
|
|
|
| |
TBR=reed@google.com
BUG=skia:517
Review URL: https://codereview.chromium.org/1259983009
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1270583003
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1254963006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Allowed project-skia-tryjob-access group to schedule builds on public
skia build buckets
R=borenet@chromium.org, rmistry@chromium.org
BUG=495680
Review URL: https://codereview.chromium.org/1256333006
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial revert of f20488b4f2, particularly
https://skia.googlesource.com/skia/+/f20488b4f2139e6ca09fee7e39b731dd8ab467db%5E%21/#F11
BUG=chromium:515366
TBR=mtklein@google.com
This is a (non-automatic) revert.
Review URL: https://codereview.chromium.org/1265993003
|
|
|
|
|
|
|
|
| |
Fix:
PM component swizzling on Macs
Serialization
Review URL: https://codereview.chromium.org/1270533003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=510931
Review URL: https://codereview.chromium.org/1269743003
|
|
|
|
|
|
| |
Now that Chrome no longer depends on it, remove dead code.
Review URL: https://codereview.chromium.org/1263013002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1262473004
|
|
|
|
|
|
|
|
|
|
| |
This doesn't really do anything yet. It's just the CPU detection code, skeleton new .cpp files, and a few little .gyp tweaks.
BUG=skia:4117
Committed: https://skia.googlesource.com/skia/+/ce2c5055cee5d5d3c9fc84c1b3eeed4b4d84a827
Review URL: https://codereview.chromium.org/1255193002
|
|
|
|
|
|
|
| |
NOTRY=true
BUG=skia:4132
Review URL: https://codereview.chromium.org/1258193004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(patchset #2 id:20001 of https://codereview.chromium.org/1229673008/)
Reason for revert:
This doesn't draw correctly, e.g. our GM test named dashcubics.
Good: https://gold.skia.org/img/images/0f7e8e226379afbad8a700e0a80fd8f1.png
Bad:
https://gold.skia.org/img/images/56ce15fc67436065a3db4b8ee31f13ae.png
Original issue's description:
> Optimize RGB16 blitH functions with NEON for ARM platform.
>
> Here are some performance resultsi on Nexus 9:
> SkRGB16BlitterBlitH_neon:
> +--------+-----------+
> |height | C/NEON |
> +--------+-----------+
> |1 | 0.888531 |
> +--------+-----------+
> |8 | 1.231800 |
> +--------+-----------+
> |18 | 1.073327 |
> +--------+-----------+
> |32 | 1.136991 |
> +--------+-----------+
> |76 | 1.174638 |
> +--------+-----------+
> |85 | 1.188551 |
> +--------+-----------+
> |120 | 1.180261 |
> +--------+-----------+
> |128 | 1.183726 |
> +--------+-----------+
> |512 | 1.220806 |
> +--------+-----------+
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/6c72d5740231f47c664a8e765a8df05cd124c88c
TBR=djsollen@google.com,caryclark@google.com,reed@google.com,bero@linaro.com,yang.zhang@linaro.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1268513003
|
|
|
|
|
|
|
| |
TBR=reed@google.com
BUG=skia:4140
Review URL: https://codereview.chromium.org/1269723002
|