- only depend on cpu-features when we know we have an NDK
- disable SkSplicer
Change-Id: I89e4cc70d6ddf0ebb7005d1cb453768d946cd205
Reviewed-on: https://skia-review.googlesource.com/7060
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is salvaged from an ancient CL or mine. Thoughts?
Change-Id: I3712ca911d1ab5def3f4dcb080a3f9e226cdd44b
Reviewed-on: https://skia-review.googlesource.com/7031
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
YUV conversion happens via SkImage now.
BUG=skia:
Change-Id: I6e1fa18effb72cbb00a173a346769b873e372c40
Reviewed-on: https://skia-review.googlesource.com/7034
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
These are enough to splice interesting SkColorSpaceXform pipelines.
SkSplicer_stages.cpp is similar to but still intentionally distinct from
SkRasterPipeline_opts. I hope to unify them next week.
unaligned_load() is nothing tricky... just a little refactor.
Change-Id: I05d0fc38dac985aa351d88776ecc14d2457f2124
Reviewed-on: https://skia-review.googlesource.com/7022
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The -1 to 1 weights reported by CTFontDescriptors have different mappings
depending on if the CTFont is native or created from a CGDataProvider.
Change-Id: I725b04a31c224a4b01c0763137fa04bb4088def7
Reviewed-on: https://skia-review.googlesource.com/6979
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
BUG=skia:6119
Change-Id: I8318cf2758042ffd0c81c5fa74240acbf7bea61f
Reviewed-on: https://skia-review.googlesource.com/6999
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
You'd think by now it would have occurred to me that mod is also a kind
of division.
BUG=skia:6087
Change-Id: I5128d09db94d06f10762ad5c23df32551c5e5855
Reviewed-on: https://skia-review.googlesource.com/6607
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
BUG=skia:
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I4f6dd002b03812d63bf62342c346ea21f6865466
Reviewed-on: https://skia-review.googlesource.com/7027
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Additionally reformat the equations to better expose the symmetry.
BUG=skia:
Change-Id: If485cc7aeae97b89dedeb4d6b23efbe945036e3a
Reviewed-on: https://skia-review.googlesource.com/7000
Reviewed-by: Greg Daniel <egdaniel@google.com>
Reviewed-by: Dean McNamee <deanm@chromium.org>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Should be no user- or test-visible changes.
BUG=skia:
Change-Id: I6499dc978a41fee344b847c118f84227271561c5
Reviewed-on: https://skia-review.googlesource.com/6906
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Stephan White <senorblanco@chromium.org>
The idea is share these standards for the following:
SkImage::readPixels()
SkCanvas::readPixels()
SkCanvas::writePixels()
SkBitmap::readPixels()
SkPixmap::readPixels()
On the raster side, SkPixmap::readPixels() is the right
place to check, because all raster calls go through
there eventually. Then at lower levels (ex: SkPixelInfo),
we can assert.
There's not really a unifying location for gpu calls,
so I've added this in multiple places. I haven't really
dug into the gpu code to SkASSERT() on invalid cases
that we will have already caught.
Follow-up work:
Similar refactor for SkReadPixelRec::trim().
Code cleanup in SkPixelInfo::CopyPixels()
BUG=skia:6021
Change-Id: I91ecce10e46c1a6530f0af24a9eb8226dbecaaa2
Reviewed-on: https://skia-review.googlesource.com/6887
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
- Implementation.
- Use in SkLinearPipeline.
TBR=mtklein@google.com
Change-Id: Ie014184469b217132b0307b5a9ae40c0c60e5fc9
Reviewed-on: https://skia-review.googlesource.com/6921
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@google.com>
This fixes an issue where color filters aren't correctly applied to color glyphs. Instead we apply the filter to the SkPaint's color which is correct for mask glyphs only.
Add color filter and alpha + various effects to coloremoji gm
Change-Id: If77dece71d43468fec65499857eaaaedb56428e9
Reviewed-on: https://skia-review.googlesource.com/6891
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
https://skia.org/?cl=6994
Change-Id: Icac009bdef49f38ae7b8f082ffda6408481a03cd
Reviewed-on: https://skia-review.googlesource.com/6994
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We can splice these stages if we drop them down to 2 at a time.
Turns out this is significantly (2-3x) faster than the status quo.
SkRasterPipeline_…
…f16_compile 1x …srgb_compile 2.06x …f16_run 3.08x …srgb_run 4.61x
Added a couple ways to detect (likely) the required VFPv4 support:
- use hwcap when available (NDK ≥21, Android framework)
- use cpu-features when not (NDK <21)
The code in SkSplicer_generated.h is ARM, not Thumb2. SkSplicer seems
to be blx'ing into it, so that's great, and we bx lr out. There's no
point in attempting to use Thumb2 in vector heavy code... it'll all be
4 byte anyway.
Follow ups:
- vpush {d8-d9} before the loop, vpop {d8-d9} afterwards,
skip these instructions when splicing;
- (probably) drop jumping stages down to 2-at-a-time also.
Change-Id: If151394ec10e8cbd6a05e2d81808488d743bfe15
Reviewed-on: https://skia-review.googlesource.com/6940
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This will hopefully bring in driver fixes, especially for Vulkan.
BUG=skia:
Change-Id: I6a8f1bf249d78d9360c52e0382250b63ae0cc96d
Reviewed-on: https://skia-review.googlesource.com/6989
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Change-Id: Ifae5618f30c2202b9083f479b58556709ff6126a
Reviewed-on: https://skia-review.googlesource.com/6990
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
The only difference is that we now also put the guard flag
SK_SUPPORT_LEGACY_AAA in SkUserConfig.h. Previously, SkAnalyticEdge.cpp doesn't
get that flag from SkScan.h and that caused many problems.
BUG=skia:
TBR=reed@google.com,caryclark@google.com
Change-Id: I134bb76cebd6fffa712f438076668765321bba3b
Reviewed-on: https://skia-review.googlesource.com/6992
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
We don't support this. F16 or F32 textures must be built with a linear
transfer function, if any.
BUG=skia:
Change-Id: Ia8d83a03d12ddc3b70f5d7e4fabed72f6c2af538
Reviewed-on: https://skia-review.googlesource.com/6978
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
(1) Parse ICC gray profiles into RGB SkColorSpace objects. This is
easy - "gray transfer fn + white point" is subset of "RGB transfer fns
+ matrix". This makes it easier/possible for the drawing code to reason
about color spaces attached to kGray buffers.
(2) Allow gray images to be tagged with gray ICCs OR rgb ICCs. ICC gray
forces to designer to use "D50 gray". It is not uncommon to see gray
images with RGB profiles - and this actually allows the designer to
choose more kinds of gray (ex: sRGB gray).
(3) Make SkJpegCodec support gray images with RGB ICCs.
(4) Make SkPngCodec support gray images with Gray ICCs.
(5) Delete gray from SkColorSpace_A2B - we no longer create these objects
for gray profiles.
BUG=skia:
Change-Id: Id5eca803798330c54a19c4657def2e5976d1941e
Reviewed-on: https://skia-review.googlesource.com/6922
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Now that SkOpts_hsw.cpp no longer hooks in SkRasterPipeline_opts,
it should be safe to try this again.
This reverts commit 86d55b312a.
Change-Id: I2d495600ca9d3a0f49c2e02fbaaae349cefac3a1
Reviewed-on: https://skia-review.googlesource.com/6985
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit b46fff60bc.
Reason for revert: possible chromium cc unit tests failure
Change-Id: Ie174c55e4d0fc3ae45854b5897ba26b7ad5a9c13
Reviewed-on: https://skia-review.googlesource.com/6981
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Reland of Original Change:
https://skia-review.googlesource.com/6260
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I809984dd9af225103bfbe83492a17c19da7c5e40
Reviewed-on: https://skia-review.googlesource.com/6980
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Add support in SKIA debugger for SkCanvas.drawImageLattice calls.
Test: Tested with an SKP from android settings app.
Change-Id: I3f39f353dca8a3a2854241e7ef995d4d8c635f3e
Reviewed-on: https://skia-review.googlesource.com/6882
Commit-Queue: Stan Iliev <stani@google.com>
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
The only difference is that we now put the guard flag SK_SUPPORT_LEGACY_AAA in
SkUserConfig.h instead of SkScan.h. Previously, SkAnalyticEdge.cpp doesn't get
that flag from SkScan.h and that caused many problems.
BUG=skia:
TBR=reed@google.com,caryclark@google.com
Change-Id: I7b89d3cb64ad71715101d2a5e8e77be3a8a6fa16
Reviewed-on: https://skia-review.googlesource.com/6972
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This reverts commit bb2339da39.
Reason for revert: Breaks MSAN
Original change's description:
> Use RasterPipeline to support full precision on 16-bit RGBA pngs
>
> TODO: Support more precision on 16-bit RGB pngs
>
> BUG=skia:
>
> CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
>
> Change-Id: I89dfef3b4887b9c4895c17309933883ab90ffa4d
> Reviewed-on: https://skia-review.googlesource.com/6260
> Reviewed-by: Mike Reed <reed@google.com>
> Reviewed-by: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Matt Sarett <msarett@google.com>
>
TBR=mtklein@chromium.org,mtklein@google.com,msarett@google.com,scroggo@google.com,reed@google.com,reviews@skia.org
BUG=skia:
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I47579c20af033a75883e2b35567cb9c690ce54b0
Reviewed-on: https://skia-review.googlesource.com/6975
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
... and copy gn to bin/ when done to make it easy to find.
Change-Id: I1ec405b4c45efb828626ff7d904a417f69b39cb2
Reviewed-on: https://skia-review.googlesource.com/6962
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Ifd194fd009196b8bee2dd83328bbe698586d72f4
Reviewed-on: https://skia-review.googlesource.com/6965
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
I missed updating this tool.
BUG=skia:
Change-Id: If5c79f0c41dd829ce8f952106660100ce4accca0
Reviewed-on: https://skia-review.googlesource.com/6963
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
TODO: Support more precision on 16-bit RGB pngs
BUG=skia:
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I89dfef3b4887b9c4895c17309933883ab90ffa4d
Reviewed-on: https://skia-review.googlesource.com/6260
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
This reverts commit 89a0e72287.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Implement Analytic AA for General Paths (with Guard against Chrome)
>
> I've set up a SK_SUPPORT_LEGACY_AAA flag to guard against Chromium layout tests. I also set that flag in this CL so theoretically this CL won't trigger any GM changes. I'll use this to verify my guard, and remove that flag and actually enables concave AAA in a future CL.
>
> When enabled, for most simple concave paths (e.g., rectangle stroke, rrect stroke, sawtooth, stars...), the Analytic AA achieves 1.3x-2x speedup, and they look much prettier. And they probably are the majority in our use cases by number. But they probably are not the majority by time cost; a single complicated path may cost 10x-100x more time to render than a rectangle stroke... For those complicated paths, we fall back to supersampling by default as we're likely to be 1.1-1.2x slower and the quality improvement is not visually significant. However, one can use gSkForceAnalyticAA to disable that fallback.
>
> BUG=skia:
>
> Change-Id: If9549a3acc4a187cfaf7eb51890c148da3083d31
> Reviewed-on: https://skia-review.googlesource.com/6091
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Yuqian Li <liyuqian@google.com>
>
TBR=caryclark@google.com,liyuqian@google.com,reed@google.com
BUG=skia:
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I13c05aaa1bcb14956bd0fe01bb404e41be75af22
Reviewed-on: https://skia-review.googlesource.com/6961
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
I've set up a SK_SUPPORT_LEGACY_AAA flag to guard against Chromium layout tests. I also set that flag in this CL so theoretically this CL won't trigger any GM changes. I'll use this to verify my guard, and remove that flag and actually enables concave AAA in a future CL.
When enabled, for most simple concave paths (e.g., rectangle stroke, rrect stroke, sawtooth, stars...), the Analytic AA achieves 1.3x-2x speedup, and they look much prettier. And they probably are the majority in our use cases by number. But they probably are not the majority by time cost; a single complicated path may cost 10x-100x more time to render than a rectangle stroke... For those complicated paths, we fall back to supersampling by default as we're likely to be 1.1-1.2x slower and the quality improvement is not visually significant. However, one can use gSkForceAnalyticAA to disable that fallback.
BUG=skia:
Change-Id: If9549a3acc4a187cfaf7eb51890c148da3083d31
Reviewed-on: https://skia-review.googlesource.com/6091
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
